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DESCRIPTION AND THEORETICAL ANALYSIS (USING SCHEMATA) OF 

PLANNER: 

A LANGUAGE FOR PROVING THEOREMS AND 
MANIPULATING MODELS IN A ROBOT* 

Abstract 

PLANNER is a formalism for proving theorems and manipulating models 
in a robot. The formalism is built out of a number of problem-solving 
primitives together with a hierarchical multiprocess backtrack control 
structure. Statements can be asserted and perhaps later withdrawn as 
the state of the world changes. Under BACKTRACK control structure, the 
hierarchy of activations of functions previously executed is maintained 
so that it is possible to revert to any previous state. Thus programs 
can easily manipulate elaborate hypothetical tentative states. In addi¬ 
tion PLANNER uses multiprocessing so that there can be multiple loci of 
control over the problem-solving. Conclusions can be drawn from the various 
changes in state. Goals can be established and dismissed when they are 
satisfied. The deductive system of PLANNER is subordinate to the hier¬ 
archical control structure in order to maintain the desired degree of 
control. The use of a general-purpose matching language as the basis 
of the deductive system increases the flexibility of the system. Instead 
of explicitly naming procedures in calls, procedures can be invoked im¬ 
plicitly by patterns of what the procedure is supposed to accomplish. 

The language is being applied to solve problems faced by a robot, to 
write special purpose routines from goal oriented language, to express 
and prove properties of procedures, to abstract procedures from proto¬ 
cols of their actions, and as a semantic base for English. 


Thesis Supervisor: Seymour Papert, Professor of Mathematics 


*This report reproduces a thesis of the same title submitted to the 
Department of Mathematics, Massachusetts Institute of Technology, 
on January 29, 1971 in partial fulfillment of the requirements for 
the degree of Doctor of Philosophy. 
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Rote to the Reader 


This paper is organized in what purports to be a logical 
systenatic fashion. The organization lakes it difficult to get a 
quick overview. The reader should not try to read the paper in a 
linear fashion froa cover to cover. If he gets stuck he should N pop 
up" one level and continue. 

M IOO HAVE BEER BARRED" 

There is an index of praiaitives at the end. There is an index to the 
syntax after the function READ. The following guide is provided for 
those readers who are not interested in reading the whole paper. 
Chapter 1 is a "hack". Chapter 2 gives the epistesological 
foundations for our approach to problea solving. Chapter 3 is a 
discursive overview of the rest of the thesis using exaaples of sone 
features of the problea solving language PLAMVEB. Many of the 
iaportaat ideas in the thesis are touched on soaewhere in the chapter. 
In chapter 4 we find a detailed explanation of the structural pattern 
aatching language BATCHLESS. Beaders who are only peripherally 
interested in pattern aatching need read only sections 4.1, 4.2# 4.3# 
and 4.4. Chapter 5 begins the systeaatic explanation of P1AHREB. It 
introduces the priaitives# data structure# and control structure of 
the language. In contrast to the quantificational calculus# the 
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semantics of PLANHEB are expressed in terns of the properties of the 

procedures which define the formalism. In chapter 7 we explain how 
properties of CLASSES procedures can be expressed and proved in the 
formalism itself. Also we attach the problem of how it is possible to 
teach a problem solver new knowledge. He explain how schemata give 
the beginning of a theorj on the comparative problem solving power of 
various computational models in chapter 6. 




1. What Achilles Said To The Tortoise 

Levis Carroll 


Achilles had overtaken the Tortoise, and had seated hiaself 
comfortably on its back. 

"So you've get to the end of our race-course?" said the 
Tortoise. "Even though it does consist of an infinite series of 
distances? I thought some viseacce or other had proved that the 
thing couldn't be done?" 

"It can be done," said Achilles. "It has been done! Solvitur 
ambulando. You see the distances vere constantly diminishing: and so- 

• n 

"But if they had been constantly increasing?" the Tortoise 
interrupted. "Bov then?" 

"Then I shouldn't be here," Achilles modestly replied; "and 
you would have got several times round the world, by this time!" 

"You flatter me— flatten, I mean," said the Tortoise; "For 
you are a heavy weight, and no mistake! Bell now, would you like to 
hear of a race-course, that most people fancy they can get to the end 
of in two or three steps, while it really consists of an infinite 
number of distances, each one longer than the previous one?" 

"Very much indeed!" said the Grecian warrior, as he drew from 
his helmet {few Grecian warriors possessed pockets in those days) an 
enormous note—book and a pencil. "Proceed! And speak slowly, please! 
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Short-hand isn’t invented yet!" 

"That beautiful First Proposition of Euclid!" the Tortoise 
murmured dreamily. "You admire Euclid?" 

"Passionately! So far, at least, as one can admire a treatise 
that won’t be published for some centuries to come!" 

"Well, now, let’s take a little bit of the argument in that 
First Proposition--just two steps, and the conclusion drawn from them. 
Kindly enter them in your note-book. And, in order to refer to them 
conveniently, let's call them A, B, and Z: 

{A) Things that are equal to the same are equal to each other. 

(B) The two sides of this Triangle are things that are equal 
to the same. 

(Z) The two sides of this Triangle are equal to each other. 

"Readers of Euclid will grant, I suppose, that Z fellows 
logically from A and B, so that any one who accepts A and B as true, 
must accept Z as true?" 

"Undoubtedly! The youngest child in a High School— as soon as 
High Schools are invented, which will not be till some two thousand 
years later—will grant that." 

"And if some reader had not yet accepted A and E as true, he 
might still accept the Sequence as a valid one, I suppose?" 

"No doubt such a reader might exist. He might say *1 accept 
as true the Hypothetical Proposition that, if A and B be true, Z must 
be true; but I don't accept A and B as true.' Such a reader would do 
wisely in abandoning Euclid, and taking to football." 
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"And aight there not also be scie reader who would say 'I 

accept A and B as true, but I don't accept the Hypothetical'?" 

"Certainly there Bight. He, also, had better take to 
foot tall • * 

"And neither of these readers," the Tortoise continued, "is as 
yet under any logical necessity to accept z as true?" 

"Quite so," Achilles assented. 

"Bell, now, I want you to consider ae as a reader of the 
second kind, and to force ae, logically, to accept Z as true." 

"A tortoise playing football would be—" Achilles was 
beginning. 

"—an anonaly, of course," the Tortoise hastily interrupted, 
"don't wander fron the point, let's have Z first, and football 
afterwards!” 

"I'b to force you to accept Z, aa I?" Achilles said ausingly. 
"And your present position is that you accept A and B, but you don't 
accept the Hypothetical—" 

"Let's call it C," said the Tortoise. 

"--but you don't accept: 

(C) If a and E are true, z Bust be true." 

"That is ay present positoa," said the Tortoise. 

"Then I aust ask you to accept C." 

"I'll do so," said the Tortoise, "as soon as you've entered it 
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in that note-book of yours. Hhat else have you got in it?" 

"Only a few memoranda," said Achilles, nervously fluttering 
the leaves: "a few memoranda of—of the battles in which I have 
distinguished myself!" 

"Plenty of blank leaves, I see!" the Tortoise cheerily 
remarked. "He shall need them all!" (Achilles shuddered.) "How write 

as I dictate: 

(A) Things that are egual to the same are egual each other. 

(B) The two sides of this triangle are things that are egual 
to the same. 

(C) If A and B are true, Z must be true. 

(Z) The two sides of this Triangle are egual to each other." 
"You should call it D, not Z," said Achilles. "It comes next 
to the other three. If you accept A and B and C, you must accept Z." 

"And why must I?" 

"Because it follows logically from them. If A and B and C are 
true, Z must be true. You don’t dispute that, I imagine?" 

"If A and B and C are true, Z must be true," the Tortoise 
thoughtfully repeated. "That's another Hypothetical isn't it? And, 
if I failed to see its truth, I might accept A and B and C, and still 

not accept Z, mightn't I?" 

"You might," the candid hero admitted; "though such obtuseness 

would certainly be phenomenal, still, the event is possible. So I 

must ask you to grant one more Hypothetical." 

"Very good. I'm guite willing to grant Z, as soon as you've 
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written it down. We sill call it 

(D) If A and B and C are true, Z aurt be true. 

"Have you entered that in your note-book?" 

"I have!" Achilles joyfully exclaiaed, as he ran the pencil 

into its sheath. "And at last we*ve got to the end of this ideal 

race-course! Sow that you accept A and B and c and D, of course you 
accept Z." 

"Do I?" said the Tortoise innocently. "Let's lake that quite 

clear. i accept a and B and C and D. Suppose I still refuse to 
accept z?" 

take you by the throat, and force you to do 
it!" Achilles triuaphantly replied. "Logic would tell you can't help 

yourself. Now that you've accepted A and B and c and D, you anst 
accept Z!' So you've no choice, you see." 

"Whatever Logic is good enough to tell ae is worth writing 

down," said the Tortoise. "So enter it in your book, please. «e will 
call it 

(E) If A and B and c and D are true, z aust be true. 

"Until I've granted that, of course, I needn't grant 2. So 
it's quite a necessary step, you see?" 

"I see," said Achilles; and there was a touch of sadness in 
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his tone 
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2. The Structural Foundations of Problea Solving 


He would like to develop a foundation far problem solving 
analogous in soae ways to the currently existing foundations for 
aatheaatics. Thus ve need to analyze the structure of foundations 
for aatheaatics. A foundation for aatheaatics aust provide a 
definitional foraalisa in which mathematical objects can be defined 
and their existence proved. For exaaple set theory as a foundation 
provides that objects aust be built out of sets. Then there aust be a 
deductive foraalisa in which fundamental truths can be stated and the 
aeans provided to deduce additional truths froa those already 

M * • .. •- -t ■< • i. ../> - . -•-£ .- - ■-■■■ ■■■■ .. • -■ .?**.•. ■ >' •-«i . • - - ... r-tf, . _ . - : :«, n .-. ... - .... ... 

established. Current aatheaatical foundations such as set theory 
seen quite natural and adequate for the vast body of classical 
aatheaatics. The objects and reasoning of aost aatheaatical domains 
such as analysis and algebra can be easily founded on set theory. The 
existence of certain astronomically large cardinals poses soae 
problems for set theoretic foundations. However, the problems posed 
seea to be of practical iaportance only to certain category theorists. 
Foundations of aatheaatics have devoted a great deal of attention to 
the problems of consistency and completeness. The problea of 
consistency is important since if the foundations are inconsistent 
then any formula mhatsoever may be deduced, thus trivializing the 
foundations. Semantics for foundations of mathematics are defined 
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model theoretically in terms of the notion of satisfiability. The 

problem of completeness, is that for a foundation of mathematics to be 
intuitively satisfactory all the true formulas should be proveable 
since a foundation for mathematics aims to be a theory of mathematical 
tr uth. 

Similar fundamental guestions must be faced by a foundation 
for problem solving. However there are some important differences 
since a foundation for problem solving aims more to be a theory of 
actions and purposes than a theory of mathematical truth. A 
foundation for problem solving must specify a goal-oriented formalism 
in which problems can be stated. Furthermore there must be a 
formalism for specifying the allowable methods of solution. As part 
of the definition of the formalisms, the following elements must be 
defined: the data structure, the control structure, and the 

primitive procedures. Being a theory of actions, a foundation for 
problem solving must confront the problem of change: How Can account 
be taken of the changing situation in the world? In order for there 
to be problem solving, there must be an active agent called a problem 
solver. A foundation for problem solving must consider how much 
knowledge and what kind of knowledge problem solvers can have about 
themselves. In contrast to the foundation of mathematics, the 
semantics for a foundation for problem solving should be defined in 
terms of properties of procedures. He would like to see mathematical 
investigations on the adequacy of the foundations for problem solving 
provided by FLASHES. In chapter 8 we have begun one kind of such an 




investigation. 

To be more specific, a foundation for problem solving Bust 
concern itself with the following complex of topics: 

PROCEDURAL EMBEDDING: How can "real world" knowledge be 
effectively embedded in procedures. Hhat are good ways to express 
problem solution methods and how can plans for the solution of 
problems be formulated? 

GENERALIZED COMPILATION: that are good methods for transforming 
high level goal-oriented language into efficient algorithms. 

VERIFICATION: How can it be verified that a procedure does what 

is intended. 

PROCEDURAL ABSTRACTION: What are good methods for abstracting 
general procedures from special cases. 

One formulation of a foundation for problem solving reguires 
that there should be two distinct formalisms: 

1: A METHODS formalism which specifies the allowable methods of 

solution 

2: A PROBLEM SPECIFICATION formalism in which to pose problems. 

The problem solver is expected to figure out how to combine its 
available methods in order to produce a solution which satisfies the 
problem specification. One of the aims of the above formulation of 
problem solving is to clearly separate the methods of solution from 
the problems posed so that it is impossible to "cheat" and give the 
problem solver the methods for solving the problem along with the 
statement of the problem. Be propose to bridge the chasm between the 
methods formalism and the problem formalism. Consider more carefully 
the two extremes in the specification of processing: 
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A: Explicit processing (e.g. methods) is the ability to specify 

and control actions down to the finest details. 

B: Implicit processing (e.g. problems) is the ability to specify 

the ena result desired and not to say much about how xt should be 

achieved. 

PLAHMEfi attempts to provide a formalism in which a problem solver can 
bridge the continuum between explicit and implicit processing. He aim 
for a maximum of flexibility so that whatever knowledge is available 
can be incorporated, even if it is fragmentary and heuristic. 

PLANNER is a high level, goal-oriented formalism in which one 
can specify to a large degree what one wants done rather than how to 
do it. Many o* th»> primitives in PLANNER are concerned with 
manipulating a data base in a pattern directed fashion. Host of the 
primitives have been developed as extensions to the formalism when we 
have found problems that could not otherwise be solved in a natural 
way. Of course the trick is to incorporate the new primitive as a 
genuine extension of wide applicability. Others have suggested 
themselves as adjuncts in order to obtain useful closure properties in 
the formalism. He would be grateful to any reader who could suggest 
problems that would seem to reguire farther extensions or 
modifications to the formalism. 

There are many ways in which one can approach a description of 
PLANNER. In this section we will describe PLANNER from an Information 
Processing viewpoint. To do this we will describe the data structure 
and the control structure of the formalism. 





GLOBAL DATA BASE 

CABOVE AB 3 is not in the global 
data base 



PLANNER ALLOWS FOR THE SIMULTANEOUS 
EXISTENCE OF INCOMPATIBLE LOCAL STATES 
IN MODELS. 
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BATA STRUCTURE: 

GRAPH HEHORY forms the basis for PLANNER*s data space which 
consists of directed graphs with labeled arcs. The operation 

of PUTTING and GETTING the components of data objects have 

been generalized to apply to any data type whatsoever. Por 

example to POT the value CANONICAL on the expression <♦ X Y <* 

X Z>> under the indicator SIMPLIFIED is one way to record that 

<♦ X I <* X Z>> has been canonically simplified. Then the 

degree to which an expression is simplified can be determined 

by GETTING the value under the indicator SIMPLIFIED of the 

expression. The operations of POT and GET can be implemented 

efficiently using hash coding. Lists and vectors have been 

introduced to gain more efficiency for common special purpose 

structures. The graph memory is useful to PLANNER in many 

ways. Monitoring gives PLANNER the capability of trapping 

all read, write, and execute references to a particular data 

object. The ponitor (which is found under the indicator 

MONITOR) of the data object can then take any action that it 

sees fit in order to handle the situation. The graph meaory 

can be used to retrieve the value of an identifier i of a 

process p by GETTING the i component of p. Code can be 

commented by simply POTTING the actual comment under the 

indicator COMMENT. Also graph memory enables unique copies of 

structures to be efficiently and conveniently stored. 

DATA BASE: Hhat is most distinctive about the way in which 
PLANNER uses data is that it has a data base in which data can 

be inserted and removed. For example inserting [AT B1 P2] 
into the data base might signify that block B1 is at the place 
P2. A coordinate of an expression is defined to be an atom in 
some position. An expression is determined by its 
coordinates. Assertions are stored in buckets by their 
coordinates using the graph memory in order to provide 
efficient retrieval. In addition a total ordering is imposed 
on the assertions so that the buckets can be scrted. 
Imperatives as well as declaratives can be stored in the data 
base. He might assert that whenever an expression of the 
form [AT objectl place"! ] is removed from the data base, then 
any expression in the data base of the form [CN object! 
object2 ] should also be removed from the data base. The data 
base can be tree structured so that it is possible to 
simultaneously have several local data bases which are 
incompatible. Furthermore assertions in the data base can 
have varying scopes so that some will last the duration of a 
process while ethers are temporary to a subroutine. 


CONTROL STRUCTURE: PLANNER uses a pattern directed multiprocess 
backtrack control structure to tie the operation of its primitives 




together. 

BACKTRACKING: PLANNEE processes have the capability of 

backtracking tc previous states. A process can backtrack into 

a procedure activation (i.e. a specific instance of an 
invocation of a procedure) which has already returned with a 
result. Using the theory of comparative schematology, w« 
have proved in chapter 8 that the use of backtrack control 
enables us to achieve effects that a language (such as LISP) 
which is limited to recursive control cannot achieve. 
Backtracking preserves the nesting of the subroutine structure 
of PLANNEB while allowing the consequences of elaborate 
tentative hypotheses to be explored without losing the 
capability of rejecting the hypotheses and all of their 
consequences. A choice can be aade on the basis of the 
available knowledge and if it doesn't work, a better choice 
can be made using the new inforaation discovered while 
investigating the first choice. Also backtrack control makes 
PLANNEE procedures easier to debug since they can be run 
backwards as well as forwards enabling a problea solver to 
"zero in" on bugs. 


MULTIPEOCESSING gives PLANNEE the capability of having aore 
than one locus of control in problem solving. By using 
multiple processes, arbitrary patterns of investigation 
through a conceptual problem space can be carried out. 
Processes can have the power to create, read, write, 
interrupt, resume, single step, and fork other processes. The 
ability to single-step or to interrupt processes allows the 
definition of procedures which are NOT monotone in the sense 
of lattice theory. Potentially the failure of monotonicity is 
a serious flaw in the lattice theoretic approach towards a 
mathematical foundation for effective procedures. 

PATTJEN BISECTION combines aspects of control and data structure. 
The fundamental principle of pattern directed coaputation Is that 

a procedure should be a pattern of what the procedure is intended 

to accomplish. In other words a procedure should not only do the 

right thing but it should appear to do the right thing as well! 

PLANNEE uses pattern direction for the following operations: 

CONSTBUCTION of structured data objects is accomplished by 
templates. We can construct a list whose first eleaent is 

the value of z and whose second eleaent is the value of y by 
the procedure (x y). If x has the value 3 and y has the value 
(A B) then (x y) will evaluate to (3 (A B)). 

DECOMPOSITION is accomplished by matching the data object 
against a structured pattern. If the pattern (xl x2) is 
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aatched against the data object ((3 4) A) then xl will be 
given the value (3 4) and x2 will be given the value A. 

BETEIEVAL: An assertion is retrieved from the data base by 

specifying a pattern which the assertion aust Batch and 

thereby bind the identifiers in the pattern* For exaaple we 

can deteraine if there is anything in the data base of the 

fora [CN x A]. If [OH B A] is the only itea in the data base, 

then x is bound to B. If there is aore than one itea in the 

data base which watches a retrieval pattern, then an arbitrary 

choice is Bade. The fact that a choice was aade is reaeabered 

so that if a siaple failure backtracks to the decision, 

another choice can be aade. 

INVOCATION: Procedures can be invoked by patterns of what 

they are supposed to accoaplish. Suppose that we have a 

stopped sink. One way we could try to solve the problea would 

be to know the nane of a plunber whoa we could call. An 

alternative which is acre analogous to pattern directed 

invocation is to advertise the fact that we have a stopped 

sink and the qualifications needed to fix it. In PLANMEB this 

is acconplished by aaking the advertiseaent (i.e. a pattern 

which represents what is desired) into a goal. The procedure 

invoked by the pattern night or night not succeed in achieving 

the goal depending on the envizonaent in which it was called. 

The procedure invoked can be required to undo all the actions 

that it took tc try to achieve the goal. For exaaple if we 

were unhappy with the way in which a pluaber fixed our sink, 

we could require that he restore the situation to its previous 

state. Since aany theoreas aight aatch a goal, a 

recoaaendation is allowed as to which of the candidate 

theoreas aight be useful. The recoaaendation is a pattern 

which a candidate theorea aust natch. 

One basic idea behind PLANMEB is to exploit the duality that 
we find between certain iaperative and declarative sentences. 

Consider the stateaent (iaplies A B}. The stateaent is a perfectly 
good declarative. In addition, it can also have certain iaperative 
uses for PLANMEB. It can say that we aight set up a procedure which 
will note whether A is ever asserted and if so to consider the wisdoa 
of asserting B in turn. [Mote: it is not always wise! Suppose we 
assert <integer 0> and (iaplies <integer n> <integer (♦ n 1) >1 ]. 






Furthermore it permits us to set up a procedure that will watch to see 

if it is ever our goal to try to deduce B and if so whether A should 
be made a subgoal. Exactly the saae observations can be nade about 
the contrapositive of the stateaent {implies A B} which is (iaplies 
(not B] {not A}}. Stateaents with universal quantifiers, 
conjunctions, disjunctions, etc. can also have both declarative and 
imperative uses. PLANHEB theorems are used as iaperatives when 
executed and as declaratives when used as data. The imperative 
analogues have the advantage that they can more easily express any 
procedural knowledge that we sight have such as "Don't use this 
theorea twice". 

Our work on PLANHEB has been an investigation in PBOCEDOBAL 
EPISTEHOLOGI, the study of how knowledge can be eabedded in 
procedures. The THESIS OF PBOCEDOBAL EMBEDDING is that intellectual 
structures should be analyzed through their PBOCEDOBAL A1AL0G0ES. He 
will try to show what we aean through exaaples: 


DESCBIPTIONS are procedures which recognize how well some 
candidate fits the description. 


PATTEBNS are descriptions which natch configurations of data. 
For example <either 4 <atoaic» is a procedure which will 

recognize soaethiag which is either 4 or is atonic. 


DATA TTPES are.patternsused in declarations of 
range and doaain of procedures and identifiers. 


ns of the allowable 
iers. Bore 


generally, data types have analogues in the fora of procedures 
which create, destroy, recognize, and transfora data. 


GBAHHABS: The PBOGBAHHAB language of Terry Hinograd another 
step towards one kind of procedural analogue for natural 
language graaaar. 
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SCflBMATIC DRAWINGS have as their procedural analogue methods 
for recognizing when particular figures fit within the 
schemata. 

PROOFS correspond to plans for recognizing and expanding valid 
chains of deductions. Indeed many proofs can fruitfully be 

considered to define procedures which are proved to have 

certain properties. For exaaple a proof by mathematical 

induction of a effective for aula p[n] can be considered to be 

a proof that the following function always returns "TRUE": 

p[n] :» if p[0] then "1BUE" else p[n-1} 

Conversely, proofs by execution induction cf properties of 
procedures can be used to demonstrate aatheaatical facts. For 

example proofs by execution induction can iaitate proofs by 

aatheaatical induction: 


.n" 


<f n> := <repeat 

Intent: p[i] 

<cond 

[<is? .i .n> 

;"if .i is equal to .n then 

exit with the value 

<.out .n>]> 

<_ :i <♦ .i 1» 

;"else increaent i ar d repeat"> 


out 
"ini 


Ui 


i 0]] 


lalize i to C" 


Proving the intention p[i] by execution induction will 
establish that for all n we nave p[n]. Proofs by execution 

induction enable global properties (such as convergence and 

equivalence) to be proved by purely local analysis. 

HODELS are collections of procedures for simulating the_ 
behavior of the systea being modeled. HODELS of PROGRAMS are 

procedures for defining properties of procedures and 

attempting’ to verify the properties so defined. Models of 

programs can be defined by procedures which state the 

relations that must hold as control passes through the 

program. 


PLANS are general, goal oriented procedures for attempting to 
carry out some task. 

TBEOREBS of the QUAHTIFICATIOHAL CALCULUS have as their, 
analogues procedures for carrying out the deductions vhich are 

justified by the theorems. For example, consider a theorem of 
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the fora {IMPLIES x y}. One procedural analogue of the 
theorea is to consider whether x should be aade a subgoal in 
order to try to prove soaething of the fora y. 


DRAWINGS: The procedural analogue of a drawinq is a procedure 
for aakxng the drawing. Bather sophisticated display* 

processors have been constructed for Baking drawinos on 
cathode ray tubes. y 


RECOMMENDATIONS:PLANNER has priaitives which allow 
recoaaendations as to how disparate sections of goal oriented 

language should be linked together in order to acconplish soae 
particular task. 


GCAL TREES are represented by a snapshot of the instantaneous 
configuration of problea solving processes. 

One corollary of the thesis of procedural enbedding is that 
learning entails the learning of the procedures in which the knowledge 
to be learned is eabedded. Another aspect of the thesis of procedural 
—. eabedding is that the process of going froa general goal oriented 

P& ; •" •' ■■■■ •’ ? •:•••. ."V ' /■■ •: r‘. ,=’V -?J' «*&.•■. *:n 4 .‘ ■: ~ ; -0.^-jffjUr JiW • ST':" •• \f •. v*r: : _ ■:> ■■ " ^?:15: r^'v. \ . •• ? > . . ;-WK" f? - 

language which is capable of accoaplishing scae task to a special 
purpose, efficient, algorithms especially designed for the task should 
itself be aechanized. By expressing the properties of the special 
purpose algoritha in terns of their procedural analogues, we can use 
the analogues to establish that the special purpose routine does in 
fact do what it is intended. 


Froa the above observations, we have constructed a foraalisa 
that peraits both the iaperative and declarative aspects of stateaents 
to be easily nanipulated, PLANNER uses a pattern-directed inforaation 
retrieval systea. The data base is interrogated by specifying a 
pattern of what is to be retrieved, instead of having to explicitly 
naae procedures which are to be called, they can be invoked iaplicitly 
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by a pattern (this important concept is called PATTERN-DIRECTED 
INVOCATION). when a statement is asserted, recommendations determine 
what conclusions will te drawn iron the assertion. Procedures can 
make recommendations as to which theorems should be used in trying to 
an conclusions from an assertion, and they can recommend the order 
in which the theorems should be applied. Goals can be created and 
automatically dismissed when they are satisfied. Objects can be found 
from schematic or partial descriptions. Provision is made for the 
fact that statements that were once true in a model nay no longer be 
true at some later tine and that consequences must be drawn from the 
fact that the state of the model has changed. Assertions and goals 
created within a procedure can be dynamically protected against 
interference from other procedures, onlike some other formalisms such 
as GPS, PLANNEE has no explicit goal tree. Instead the computation 
itself can be thought to be investigating some conceptual problem 
space. primitives for a multiprocess backtrack control structure 
give flexibility to the ways in which the conceptual problem space can 
be investigated. Procedures written in the formalism are extendable 
in that they can make use of new knowledge whether it be primarily 
declarative or imperative in nature. Hypotheses can be established and 
later discharged. PLANNER has been used to write a block control 
language in which we specify how blocks can be moved around by a 
robot. Ne would like to write a structure building formalism in 
which we could provide descriptions of structures (such as houses and 
bridges) and let PLANNER figure out how to build them. The logical 



a 


deductive system used by PLANNER is subordinate to the hierarchical 

control structure of the language. PLANNER theorems operate within 
context consisting of return addresses, goals, assertions, bindings, 
and local changes of state that have been Bade to the global data 
base. Through the use of this context ve can guide the conputation 
and avoid doing basically the sane work over and over again. For 
exaaple, once we deteraine that we are working within a group (in the 
aatheaatical sense) we can restrict our attention to theoreas for 
working on groups since we have direct control over what theoreas will 
be used. PLANNER has a sophisticated deductive systea in order to 
give us greater power over the direction of the computation. Of 
course procedures written in PLANNER are not intrinsically efficient. 

A great deal of thought and effort aust be put into writing efficient 
procedures. PLANNEB does provide soae basic aechanisas and 
priaitives in which to express problea solving procedures. The 
control structure can still be used when we liait ourselves to using 
resolution as the sole rule of inference. A unifora proof procedure 
gives very little control over how or when a theorea is used. The 
problea is one of the level of the interpreter that is used. A 
digital coaputer by itself will only interpret the hardware 
instructions of the aachine. A higher level interpeter such as LISP 
*iil interpret assignaents and recursive function calls. At a st il l 
higher level an interpreter such as HATCBLESS will interpret patterns 
for constructing and decomposing structured data. PLANNER can 
interpret assertions, find statements, and goals. It goes without 
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saying that code can be compiled for any of the higher level 

interpeters so that it actually runs under a lower level interpreter. 
In general higher level interpreters have greater choice in the 
actions that they can take since instructions are phrased more in 
terns of goals to be achieved rather than in terns of explicit 
elementary actions. The problem that we face is to raise the level of 
the interpreter while at the same time keeping the actions taken by it 
under control. Due to its extreme hierarchical control and its 
ability to make use cf new imperative as well as declarative 
knowledge, it is feasible to carry out very long chains of inference 
in PLANNEE without extreme inefficiency. 

Be are concerned as to how a theorem prover can unify 
structural problem solving methods with domain dependent algorithms 
and data into a coherent problem solving process. By structural 
methods we mean those that are concerned with the formal structure of 
the argument rather than with the semantics of its domain dependent 
content. 

An example of a structural method is the "consequences of the 
consequent" heuristic. By the CONSEQUENCES CF THE CONSEQUENT 
heuristic, we mean that a problem solver should lock at the 
consequences of the goal that is being attempted in order to get an 
idea of some of the statements that could be useful in establishing or 
rejecting the goal. 

Be need to discover more powerful structural methods. PLANNEE 
is intended to provide a computational basis for expressing structural 




methods. One of the most important ideas in PLANNEE is that it brings 

some of the structural methods of problem solving out into the open 
where they can be analyzed and generalized. There are a few basic 
patterns of looping and recursion that are in constant use among 
programmers. Examples are recursion cn binary trees as in LISP and 
the FIND statement of PLANNEE. The primitive FIND will construct a 
list of the objects with certain properties. For example we can find 
five things which are on something which is green by evaluating 

<FIND 5 x 

<GOAL [ON X y]> 

<GOAL [GREEN y ]>> 

which reads "find 5 x's such that x is ON y and y is GREEN. 

The patterns of looping and recursion represent common 
structural methods used in programs. They specify how commands can be 
repeated iteratively and recursively. Cne of the main problems in 
getting computers to write programs is how to use these structural 
patterns with the particular domain dependent commands that are 
available. It is difficult to decide which if any of the basic 
patterns is appropriate in any given problem. The problem of 
synthesizing programs out of canned loops is formally identical to the 
problem of finding proofs using mathematical induction. He have 
approached the problem of constructing procedures out of goal oriented 
language from two directions. The first is to use canned loops (such 
as tie FIND statement) where we assume a-priori the kind of control 
structure that is needed. The second approach is to try to abstract 
the procedure from protocols of its action in particular cases. 
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Another structural method is EBOGBESSIVE BEFIHEHENT. The way 

problems are solved by progressive refinement is by repeated 
evaluation. Instead of trying to do a complete investigation of the 
problem space all at once, repeated refinements are made. For example 
in a game like chess the same part of the game tree might be looked at 
several times. Each time certain paths are more deeply explored in 
the light of what other investigations have revealed to be the key 
features of the position. Problems in design seem to be particularly 
suitable for the use of progressive refinement since proposed designs 
are often amenable to successive refinement. The way in which 
progressive refinement typically is done in PLAHNEE is by repeated 
evaluation. Thus the expression which is evaluated to solve the 
problem will itself produce as itsvalue an expression to be 
evaluated. 

The task of artificial intelligence is to program inanimate 
machines to perform tasks that reguire intelligence, over the past 
decade several different approaches toward A. I. have developed. 
Although very pure forms of these approaches will seldom be met in 
practice, we find that it is useful for purposes of discussion to 
consider these conceptual extremes. One approach (called results mode 
by S. Papert) has been to choose some specific intellectual task that 
humans can perform with facility and write a program to perform it. 
Several very fine programs have been written following this approach. 
One of the first was the Logic Theorist which attempted to prove 
theorems in the propositional calculus using the deductive system 
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developed in Principia Hathematica. The importance of the Logic 

Theorist is that it developed a body of techniques which when cleaned 
up and generalized have proved to be fundamental tc furthering our 
understanding of A. I. The results mode approach offers the 
potentiality of maximum efficiency in solving particular classes of 
problems. On the other hand, there have been a number of programs 
bitten from the results node approach which have not advanced our 
understanding although the programs achieved slightly better results 
than had been achieved before. These programs have been large, 
clumsy, brute force pieces of machinery. There is a clear danger that 
the results mode approach can degenerate into trying to achieve A. I. 
via the "hairy kludge a month plan**. The problems with "hairy 
kludges'* are well known. It is impossible to get such programs to 
communicate with each other in a natural amd intimate way. They are 
difficult to understand, extend, and modify because of the ad hoc way 
in which they are constructed. 

Another approach to A. I. that has been prominent in the last 
decade is that of the uniform proof procedure. Proponents of the 
approach write programs which accept declarative descriptions of 
combinatorial problems and then attempt to solve them. In its most 
pure form the approach does not permit the machine to be given any 
information as to how it might solve its problems. The character 
^*kle approach to A. I. is a modification of the uniform procedure 
approach in which the program is also given a finite state table of 
connections between goals and methods. The uniform procedure approach 
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offers a great deal of elegance and a taxiaua of a certain kind of 

generality. Current programs that iopleaent the unifoca procedure 
approach suffer froa extreae inefficiency. Be believe that the 
inefficiency is intrinsic in the approach. 

PLAHHEfi is not neccessarily general in the sane sense that a 
unifora proof procedure is general. PLAHHEfi is intended to be a 
natural coaputational basis for nethods of solving probleas in a 
domain. A coaplete proof procedure for a guantificational calculus 
is general in the sense that if one can force the Droblea into the 
fora of the input language and is prepared to wait eons if necessary, 
then the computer is guaranteed to find a solution if there is one. 

The approach taken in PLAHHEfi is to subordinate the deductive systea 
to an elaborate hierarchical control structure. Although PLABHBB 
itself is doaain independent, procedures Britten in it have differing 
overlapping degrees of doaain independence. Proponents of the uniforn 
procedure approach are apt to say that PLAHHEfi "cheats* because 
through the use of its hierarchical control structure, it is possible 
to tell the program how to try to solve its probleas. In order to 
prevent this kind of "cheating", they would restrict the input to 
consist entirely of declaratives. But surely, it is to the credit of 
a prograa that it is able to accept new imperative inroraation and 
aake use of it. A problea solver needs a high level language for 
expressing problem solving methods even if the language is only used 
by the problea solver to express its problea solving aetheds to 
itself. PLAHHEB serves both as the language in which probleas are 





posed to the problea solver and the language in which aethods of 

solution are foraulated. PLANNEB is not intended to be a solution to 
the problea of finding general aethods for reducing the coabinatorial 
search involved to test whether a given proposition is valid or not. 

It is intended to be a general foraalisa in which knowledge of a 
domain can be coabined and integrated. Bealistic problea solving 
programs will need vast aaounts of knowledge. Be consider all aethods 
of solving prcblens to be legitiaate. If a program should happen to 
already know the answer to the problea that it is asked to solve, then 
it is perfectly reasonable for the problea to be solved by table look¬ 
up. Be should use the criterion that the problem solving power of a 
prograa should increase auch faster than in direct proportion to the 
number of things that it is told. The important factors in judging a 
prograa are its power, elegance, generality, and efficiency. 
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3. Discursive Overview 


This chapter contains an explanation of some of the ideas in 
PLANNER in essay fora. It is partially based on a draft written by T. 
Binograd for the course 6.545. If the reader would like to see a more 
systematic presentation, he can consult the subsequent chapters. 

The easiest way to understand PLANNEB is to watch how it 
works, so in this section we will present a few siaple examples and 
explain the use of some of its most elementary features. These 
examples are not intended to represent TOY PBOBLEHS to serve as test 
cases for "general problem solvers". The toy problem paradigm is 
misleading because toy problems can be solved without any real 
knowledge of the domain in which the toy problem is posed. Indeed, it 
seems gauche to use any thing as powerful as real knowledge on such 
siaple problems. In contrast we believe that real world problems 
reguire vast amounts of procedural knowledge for their solution. Be 
see it as part of our task to provide the intellectual capabilities 
needed for effective problem solving. Be would like to see the toy 
problem paradigm replaced with an INTELLECTUAL CAPABILITY paradigm 
where the object is to illustrate the intellectual capabilities needed 
so that knowledge can be effectively embedded in procedures. 

First we will take the most venerable of traditional 
deductions: 
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so 


Turing is a human 

All humans are fallible 

Turing is fallible. 


It is easy enough to see how this could be expressed in the 

usual logical notation and handled by a uniform proof procedure. 
Instead, let us express it in one possible way to PLANNER by saying: 


<ASSERT [HOMAN TORING]> 

<ASSEBT <DEFINE THEOREM 1 

CONSEQUENT [Y] [FALLIBLE ?Y ] 

<GCAL [HUMAN ?Y ]»>> 

Function calls are enclosed between H <" and ">". The proof 
would be generated by asking PLANNER to evaluate the expression: 


<GCAL 


[FALLIBLE TURING]> 


The example illustrates several points about PLANNER. First, 
there are at least two different kinds of information stored in the 
data base: declaratives and imperatives. Notice that for complex 
sentences containing quantifiers or logical connectives we have a 
choice whether to express the sentence by declaratives or by 
imperatives. 

Second, one of the most important points about ILANNER is that 
it is ar evaluator for statements. It accepts input in the form of 
expressions written in the PLANNER language and evaluates them, 
producing a value and side effects. ASSERT is a function which, when 
evaloated, stores its argument in the data base of assertions. In 
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this exaaple we have defined a theorea of the CONSEQUENT type [we will 

see other types later]. This states that if we ever want to establish 
a goal of the fora [FALLIBLE ?XJ, ve can do this by accoaplishing tha 
goal [HUBAN ?X ], where T is an identifier. The strange prefix 
character "? H is part of PLANNEE*s pattern Batching capabilities 
[which are extensive and make use of the pattern-natching language 
HATCHLESS which is explained in chapter 4 of the dissertation]. If we 
ask PLANNEE to prove a goal of the fora [A X], there is no obvious way 
of knowing whether A and X are constants [like TUBING and HUBAN in the 
exaaple ] or identifiers. LISP solves this problea by using the 
function QUOTE to indicate constants. In pattern aatching this is 
inconvenient and aakes "ost patterns auch bulkier and aore difficult 
to read. Instead, PLANNEE uses the opposite convention — a constant 
is represented by the atoa itself, while an identifier aust be 
indicated by adding an appropriate prefix. This prefix differs 
according to the exact use of the identifier in the pattern, but for 
the tine being let us just accept "? M as a prefix indicating an 
identifier. The definition of the theorea indicates that it has one 
identifier, X by the [X] following CONSEQUENT. 

The third stateaent illustrates the function GCAL, which 
tries to prove an assertion. This can function in several ways. If 
we had asked PLANNEE tc evaluate <GOAL [HUBAN TUBING]> it would have 
found the reguested assertion iaaediately in the data base and 
succeeded [returning as its value soae indicator that it had 
succeededj. However, [FALLIBLE TUBING ] has not been asserted, so ve 
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oust resort to theoreas to prove it. Later we will see that a GOAL 

statement can give PLANNEB various kinds of advice on which theoreas 
are applicable to the goal and should be tried. Por the moment, take 
the default case, in which the evaluator tries all theoreas whose 
conseguent is of a fora which Batches the goal [i.e. a theorea with a 
conseguent [?z TUBING] would be tried, but one of the fora [HAPPY ?Z ] 
or [FALLIBLE ?Y ?Z] would not]. Assertions can have an arbitrary list 
structure for their format — they are not United to two~meaber lists 
or three-meaber lists as in these ezaaples. The theorea we have just 
defined would be found, and in trying it, the natch of the coaseguence 
to the goal would cause the identifier Y to be bound to the constant 
TUBING. Therefore, the theorea sets up a new goal [HUHAN TUBING] and 
this succeeds ianediately since it is in the data base. In general, 
the success of a theorea will depend on evaluating a PLANNEB prograa 
of arbitrary complexity, in this case it contains only a single GOAL 
statement, so its success causes the entire theorea to succeed, and 
the goal [FALLIBLE TUBING] is proved. The following is the protocol 
of the evaluation: 

<GOAL [FALLIBLE TUBING]> [FALLIBLE TUBING] is not in the data base 
so atteapt to invoke a theorea to esablish the goal 
enter THE0BEH1 
Y becoaes TUBING 

<G0AL [HUHAN TUBING]> is satisfied since the goal is is the 
data base 

return [FALLIBLE TUBING] 

The way in which identifiers are bound by Batching is of key 
importance to PLANNEB. Consider the guestion "Is anything fallible?", 
or in logic [EXISTS X [FALLIBLE X]]. This could be expressed in 
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PLANNER as: 

<PROG [X] <GOAL [IALLI8LE ?X]» 

Notice that PROG [PLANNER’S equivalent of a LISP PROG] in this 
case acts as an existential quantifier. It provides a binding-place 
for the identifier X, tut does not initialize it — it leaves it in a 
state particularly marked as unassigned. To answer the guesticn, we 
ask PLANNER to evaluate the entire PROG expression above. To do this 
it starts by evaluating the GOAL expression. This searches the data 
base for an assertion of the fora [FALLIBLE ?X ] and fails. It then 
looks for a theorem with a consequent of that form, and finds the 
theorem we defined above. Now when the theorem is called, the 
identifier Y in the theorem is linked to the identifier X in the goal, 
but since X has no value yet, Y does net receive a value. The theorem 
then sets up the goal [HUMAN ?Y] with Y as an identifier. The PLANNEB 
primitive GOAL uses the data-base retrieval mechanism tc look for any 
assertion which matches that pattern [i.e. an instantiation], and 
finds the assertion [HUMAN TURING]. This causes Y [and therefore X] 
to be bound to the constant TURING, and the theorem succeeds, 
completing the proof and returning the value [FALLIBLE TUBING]. 

There seems to be something missing. So far, the data base 
has contained only the relevant objects, and therefore PLANNER has 
found the right assertions immediately. Consider the problem ve would 
get if we added new information by evaluating the statements: 

<ASSEBT [HOMAN SOCRATES]> 

<ASSERT [GREEK SOCRATES]> 
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Our data base new contains the assertions: 

[HOMAN TUBING 1 

[HOMAN SOCRATES] 

[GREEK SOCRATES] 
and theorem*!: 

CONSEQUENT [ I 1 [FALLIBLE ?I ] 

<GOAI fHUHAN ?Y]» J 

What if we new ask, "Is there a fallible Greek?** In PLANNER we 
would do this by evaluating the expression: 

<PROG [X] 

<GOAt [ FALLIBLE ?X]> 

<GOAL [GREEK ?X]» 

If PLANNER runs into a failure trying to evaluate an expression, then 
it backtracks to the last decision that was made and dumps the 
responsibility of hew to proceed on the procedure which made the 
decision. Notice what night happen. The first GOAL may be satisfied 
by exactly the same deduction as before, since we have not removed 
information. If the data-base retriever happens to run into TUBING 
before it finds SOCBITES, the goal [HUMAN ?y ] will succeed, binding Y 
and thus X to TUBING. After [FALLIBLE ?X ] succeeds, the PBOG will 
then establish the new goal [GREEK TUBING], which is doomed to fail 
since it has not been asserted, and there are no applicable theorems. 
If we think in LISP terns, this is a serious problem, since the 
evaluation of the first GOAL has been completed before the second one 
is called, and the "stack" now contains only the return address for 
PROG and the identifier X. If we try to go back to the beginning and 
start over, it will again find TORING and so on, ad infinitum. 
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One of the acst important features of the PLANNER language is 

that backtracking in case of failure is always possible, and aoreover 
this backtracking can go to the last place where a decision of anv 
sort was nade. Here, the decision was to pick a particular assertion 
fron the data base to natch a goal. Another kind of decision is the 
choice of a theorem to try to achieve a goal. PLANNER keeps enough 
information to change any decision and send evaluation back down a new 

path. 

In our exaaple the decision was made inside the theorea for 
FALLIBLE, when the goal [HOHAN ?Y] was watched to the assertion [HONAN 
TOEING]. PLANNER will retrace its steps, try to find a different 
assertion which matches the goal, find [HOHAN SOCRATES], and continue 
with the proof. The theorem will succeed with the value [FALLIBLE 
SOCRATES], and the PROG will proceed to the next expression, <GOAL 
[GREEK ?X]>. Since X has been bound to SOCRATBS, this will set up the 
goal [GREEK SOCRATES] which will succeed iaaediately by finding the 
corresponding assertion in the data base. Since there are no more 
expressions in the PROG, it will succeed, returning as its value the 
value of the last expression, [GREEK SOCRATES]. The whole course of 
the deduction process depends on the failure mechanism for 
backtracking and trying things over [this is actually the process of 
trying different branches down the conceptual goal tree.] This then is 
the PLANNER executive which establishes and nanipulates subgoals in 
looking for a proof. 

Re would now like to give a somewhat more formal description 
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of the behavior of PLANNER ontheabove problea. If ve intoduce 

suitable notation out problea solving protocols can be aade auch aore 
succinct and their structure aade visible. Also by formalizing the 
notions, ve can aake PLARNEB construct and analyze protocols. This 
provides one kind of tool by which PLANREB can understand its own 
behavior and aake generalizations on how to proceed. 

In this case the protocol is: 


1: enter PBOG 

2: X is rebound but not initialized 

3: <GOAL [FALLIBLE ?X]> will attempt a pattern directed 

invocation since nothing in the data base Batches [FALLIBLE 7X1. 

4: enter THE0BEH1 

5: aatch [FALLIBLE ?Y] with [FALLIBLE ?X] thus linking I to I 

the situation is shown in snapshot nuaber 1 

6: <GOAL [HUMAN ?I]> finds [BOHAH TUBING] in the data 

base 

7: Y gets the value TUBING thus giving X the value 

TUBING ... 

8: return [HUHAN TUBING] 

9: THECBEH1 returns [FALLIBLE TUBING] 

10: <GOAL [GREEK TUBING ]> fails since it is not in the data base 
and there are no Batching conseguents 

Thus PLARNEB Bust backtrack to step 7 and try again* The situation is 
shown in snapshot nuaber 2. For the convenience of the reader# we 
will repeat the first six steps froa above and then continue the 
protocol. 

1: enter PBOG 

2: X is rebound but not initialized 
3: <G0AL [FALLIBLE ?X]> 

4: eater THEOBBB1 

5: Batch [FALLIBLE ?I] with [FALLIBLE ?X] thus linking T to X 

6*: <GOAL [HUHAN ?Y]> finds [HUHAN SOCBATIS] in the data 
base 

lit Y gets the value SOCBATES thus giving X the value 
SOCBATBS 

12: return [FALLIBLE SOCBATBS] 


•Sffl 
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13: THEOREM1 returns [FALLIBLE SOCBATES] 

14: <GOAL [GREEK SOCRATES ]> 

15: return [GREEK SOCRATES] as the top level value 

The situation is shown in snapshot number 3. 

So far we have seen that although PLANNER is written as an 
evaluator, it differs in several critical ways from anything which is 
normally considered a programaing language. First, it is goal- 
directed. Theorems can be thought of as subroutines, but they can be 
called by specifying the goal which is to be satisfied. This is like 
having the abilitiy to say "Call a subroutine which will achieve the 
desired result at this point." Second, the evaluator has the 
mechanism of success and failure to handle the exploration of the 
conceptual goal tree. In PLASHES there is no explicit goal tree. The 
conceptual goal tree is represented by a SNAPSHOT of a CONFIGURATION 
of PROCESSES. Thus PLANNER has powerful control structure primitives 
to allow the conceptional goal structure to be easily and naturally 
reflected in the execution of PLANNER processes, ether evaluators, 
such as LISP, with a basic recursive evaluator have no way to do this. 
One of our current areas of research is to increase the richness of 
the machinery provided by PLANNER to guide the movement to the goal. 
Third, PLANNER contains a large set of primitive commands for matching 
patterns and manipulating a data base, and for handling that data base 
efficiently. 

On the other side, we can ask how it differs froa other 
theorem provers. Hhat is gained by writing theorems in the form of 
programs, and giving them power to call other programs wnich 
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manipulate data? The key is in the fori of the data the theorem* 

pro vet can accept. Host systeas take declarative intonation, as in 
predicate calculus. This is in the fori of expressions which 
represent "facts" about the lorld. These are aanipulated by the 
theorem-prover according to sole fixed uniform process set by the 
system. PLANHIR can sake use of imperative information, telling it 
how to go about proving a subgoal, or to sake use of an assertion. 

This produces shat is called HIERARCHICAL control structure. That is, 
any theorem can indicate shat the theorem prover is supposed to do as 
it continues the procf. It has the full power to evaluate expressions 
shich can depend on both the data base and the subgoal tree, and to 
use its results to control the farther proof by making assertions, 
deciding shat theorems are to be used, and specifying a seguence of 
steps to be followed. Rhat does this mean in practical terms? In 
what way does it make a "better" theorem prover? Re will give several 
examples of areas where the approach is important. 

First, consider the basic problem of deciding what subgoals to 
try in attempting to satisfy a goal. Very often, knowledge of the 
subject matter will fell us that certain methods are very likely to 
succeed, others may be useful if certain other conditions are present, 
while others may be possibly valuable, but not likely. Re would life 
to have the ability to use heuristic programs to determine these facts 
and direct the theorem prover accordingly. It should be able to 
direct the search for goals aad solutions in the best way possible, 
and he able to bring as much intelligence as possible to bear on the 





decision. In FLAHNEB this is done by adding to out GOAL statement a 

recoemendation list which can specify that GALT certain theorems are 
to be tried, or that certain ones are to be tried FIRST in a specified 
order. Since theorems are programs, subroutines of any type can be 
called to help sake this decision before establishing a new GOAL. 

Each theoren has a sane [in oar definition on page 1, the theoren was 
given the nane THEOREM 1 ], to facilitate referring to then explicitly. 

Another inportant problen is that of naintaining a data base with 
a reasonable aacunt of naterial. Consider the first example above. 

The stateaent that all hnaans are fallible, while unambiguous in a 
declarative sense is actually aabiguous in its iaperative sense [i.e. 
the way it is to be used by the theorea prover]. The first way is to 
simply use it whenever we are faced with the need to prove [FALLIBLE 
?X ]• Another way night be to watch for a stateaent of the forn 
[HUHAN ?XJ to be asserted, and to iaaediately assert [FALLIBLE ?X] as 
well. There is no abstract logical difference, but the iapact on the 
data base is tremendous. The aore conclusions we draw when 
information is asserted, the easier proofs will be, since they will 
not have to sake the additional steps to deduce these consequences 
over and over again. However since we don’t have infinite speed and 
size, it is clearly folly to think of deducing and asserting 
everything possible [or even everything interesting] about the data 
when it is entered. If we sere working with totally abstract 
aeaningless theoreas and axioms [an assumption which would not be 
incompatible with aany theorea-proving schemes], this would be an 
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insoluble dilemma. But PLANNER is designed to work in the real world* 

where our knowledge is such wore structured than a set of axioms and 
rules of inference. We may very well* when we assert [LIKES ?X 
POETRY] want to deduce and assert [HUHAN ?X]* since in deducing things 
about an object* it will very often be relevant whether that object is 
human* and we shouldn't need to deduce it each time. On the other 
hand* it would be silly to assert [HAS-AS-PABT ?X SPLEEN]* since there 
is a horde of facts equally important and equally limited in use. 

Part of the knowledge which PLANNEfi should have of a subject, then* is 
what facts are important* and when to draw consequences of an 
assertion. This is dene by having theorems of an antecedent type: 

<ASSEBT <DEf INE THE0REH2 

ANTECEDENT [X Y] [LIKES ?X ?Y] 

ASSERT [HUMAN ?X]»» 

This says that when we assert that X likes something* we 
should also assert [HUMAN ?x ]. Of course* such theorems do not have to 
be so simple. A fully general PLANNER program can be activated by an 
ANTECEDENT theorem* doing an arbitrary [that is* the programmer 
whether he be nan or machine has free choice] amount of deduction, 
assertion, etc. Knowledge of what we are doing in a particular 
problem may indicate that it is sometimes a good idea to do this kind 
of deduction* and other times not. As with the CONSEQUENT theorems, 
PLANNER has the full capacity when something is asserted* to evaluate 
the current state of the data and proof* and specifically decide which 
ANTECEDENT theorems should be called. 

PLANNEE therefore allows deductions to use all sorts of 




knowledge about the subject natter which go far beyond the set of 

axions and basic deductive rules. PLANNER itself is subject- 
independent, but its power is such that the deduction process never 
needs to operate on such a level of ignorance. The prograaner can put 
in as nuch heuristic knowledge as he wants to about the subject, just 
as a good teacher would help a class to understand a nathenatical 
theory, rather than just telling chen the axions and then giving 
theorens to prove. 

Another advantage in representing knowledge in an imperative 
form is the use of a theorem prover in dealing with processes 
involving a sequence of events. Consider the case of a robot 
manipulating blocks on a table. It might have data of the form, 

"block1 is on block2," "blcck2 is behind block3", and "if x is on y 
and you put it on z, then x is on z, and is no longer on y unless y is 
the same as z". Hany examples in papers on theorem provers are of 
this form [for example the classic "monkey and bananas" problem]. The 
problem is that a declarative theorem prover cannot accept a statement 
like [OH B1 B2 ] at face value. It clearly is not an axiom of the 
system, since its validity will change as the process goes on. It 
usually is put in a form (OH B1 B2 SO] where SO is a symbol for an 
initial state of the world. The third statement might be expressed 
as: 

[FOB-ALL TOPBLOCK HEtSOPPOBT CLDSOPPOBT S 
[AND 

[ON TOPBLOCK NEHSOPPOBT [POT TOPBLCCK HEISOPPOBT SI] 
[OB 

[EQUAL NEffSUPFCRT OLDSUPPOET] 
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[HOT [CN 

TOPBLCCK 

OLDSUPPOBT 

[PUT TCPBLOCF NEWSUPPORT S]]]]]] 

In this representation, [PUT X Y S] is the state which results 
from putting X on Y when the previous state was Sr We run into a 
problem when we try to ask [CN Z W [PUT X Y S]] i.e, is block Z on 
block W after we put X on Y? A human knows that if we haven*t touched 
Z or W we could just ask [ON Z W S] but in general it may take a 
complex deduction to decide whether we have actually moved them, and 
even if we haven't, it will take a whole chain of deductions [tracing 
back through the time sequence] to prove they haven't been moved. In 
PLANNER, where we specify a process directly, this whole type of 
problem can be handled in an intuitively more satisfactory way by 
using the primitive function ERASE. 

Evaluating <ERASE [CN ?X ?Y]> removes the assertion [ON ?X ?Y] 
from the data base. If we think of theorem provers as working with a 
set of axioms, it seems strange to have function whose purpose is to 
erase axioms. If instead we think of the data base as the "state of 


the world" and the operation of the prover as manipulating that state, 
it allows us tc make great simplifications. Now we can simply assert 
[ON B1 B2] without any explicit mention of states. We can express the 
necessary theorem as: 


<ASSERT <DEFIN£ THE0REB3 

<CCNSEQUENT [TCPBLOCK NEWSUPPCBT OLDSUPPOBT 


[POT ?TOPBLOCK 7NEWSDPP0BT] 

<G0A1 [ON 7T0PBL0CK 7CLDSDPPCBT]> 
<EBASE [ON 7T0PBLOCK 7CLDSUPP0BT ]> 


] 


<ASSEB1 [ON 7TCPBL0CK YNEWSUPPOBT ]»» 
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This says that whenever we want to satisfy a goal of the form 

[POT ?TOPBLOCK 7NEWSBPP0RT ], we should first find out what thing 
CLDS0PP08T the thing TCPBLOCK is sitting on, erase the fact that it is 
sitting on OLDSUPPORT, and assert that it is sitting on NEWSUPPORT. 

We could also do a number of other things, such as proving that it is 
indeed possible to put TOPELCCK on NEWSUPPORT, or adding a list of 
specific instructions to a movement plan for an arm to actually 
execute the goal. In a more complex case, other interactions might be 
involved. For example, if we are keeping assertions of the fora 
[ABOVE ?X ?Y ] we would need to delete those assertions which became 
false when we erased [CN ?X ?Z ] and add those which became true when 
we added [Oh ?X ?T ]. ANTECEDENT theorems would be called by the 
assertion [ON ?X ?Y] to take care of that part, and a similar group 
called ERASING theorems can be called in an exactly analogous way when 
an assertion is erased, to derive conseguences of the erasure. Again 
we emphasize that which of such theorems would be called is dependent 
on the way the data base is structured, and is determined by knowledge 
of the subject matter. In this example, we would have to decide 
whether it was worth adding all of the ABOVE relations to the data 
base, with the resultant need to check them whenever something is 
moved, or instead to emit them and take time to deduce them frem the 
ON relation each time they are needed. 

Thus in PLANNEE, the changing state of the world can be 
mirrored in the changing state of the data base, avoiding any need to 
make explicit mention of states, with the requisite overhead of 






3. page 52 


deductions. this is possible since the information is given in an 

imperative fora, specifying theorems as a series of specific steps to 
be executed. PIANNEB also allows the construction of local data bases 
called states which are variants of the global data base. Evaluation 
of PLANNEB expressions is carried cut relative to a local state. Thus 
simultaneous consideration can be given to two inccnpatible states of 
the world by explicitly calling the evaluator to evaluate statements 
in the two states. 

If we look back to the distinction between assertions and 
theorems made at the beginning of this chapter, it would seem that we 
have established that the base of assertions is the "current state of 
the world", while the base of theorems is our permanent knowledge of 
how to deduce things from that state. This is not exactly true, and 
one of the most exciting possibilities in PLANNER is the capability 
for the program itself to create and modify the PIANNES functions 
which make up the theorem base. Bather than simply making assertions, 
a particular PLANNEB function might be written to put together a new 
theorem or make changes to an existing theorem, in a way dependent on 
the data and current knowledge. It seems likely that meaningful 
"teaching" involves- this type of behavior rather than simply modifying 
parameters or adding more individual facts [assertions] to a 
declarative data base. 

For example suppose we are given the following protocols for a 
function f. An expression such as "new [5 * 4]" means that we are 
introducing a new identifier which is 5 * 4 * 20. 
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<f C> : 0=0 IS TBOE SC 1 
Thus <f 0> * 1 


. The above expression reads, 
which is true so the answer is 1". 

O 


"to compute <f 0> you test 0=0 


<f 1> : 1=0 IS FALSE SO 

1 * new [1-1] 0=0 IS TBOE SO 1 
Thus <f 1> = 1 


. . . . The above expression reads, "to compute <f 1> you test 1=0 

which is false so the answer is 1 times the quantity which is computed 

by first computing the intermediate result 1-1 then testing if 0=0 
which is true so the guantity is 1." 


<f 2> J 2=0 IS FALSE SO 

2 * new [2-1] 1=0 IS FALSE SO 

1 * new [1-1] 0=0 IS TBOE SO 1 
Thus <f 2> = 2 * 1 * 1=2 


<f 3> : 3=0 IS 
3 * new 

2 * 

Thus <f 3> = 3 


FALSE SO 

£3-1] 2=0 IS FALSE SO 
new [2-1] 1=0 IS FALSE SC 
1 * new [1-1] 0=0 IS TBOE SO 1 
* 2 * 1 * 1 * 6 


By the process of "variabalization", we conclude that the 
above protocols are compatible with the following program which is in 
the form of a tree [which we shall call the protocol tree]. 

<f x0> = if xC=G then 1 

else xO * new [£x0-1J=x1] if x1=0 then 1 

else x 1 * new [£x1-1]=x2] if x2=G then 1 

else x2 * new [[x2-1]=x3] 

if x3=0 then 1 
else.., 


How by identifying indistinguishable nodes on the protocol tree, we 
obtain: 

<f x> = if x=0 then 1 

else x *<f [x-1]> 
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The reader will note that f is the factorial function. P3.AHSEB 

procedures and theoreas can be tanght in precisely the saae fashion 
[which we call procedural abstraction], Por example, the coaputer can 
be taught to build a wall or recognize a tower froa exaaples* The 
reader is cautioned that although we shall speak of the coaputer being 
"taught", we do not assume that anything like what has been 
classically described as "learning" is taking place. Me assuae that 
the teacher has a good working aodel of the student that is being 
taught and that he honestly attenpts to convey a certain body of 
knowledge to the student. Of course the student will be told anything 
which aight help hia to understand the material faster. 

Procedural abstraction is one way in which a special purpose 
routine can be constructed froa general goal oriented language, Be 
would like to express the intended properties of the special purpose 
routine so that we can establish that the routine really does shat it 
is supposed to do. For exaaple we sight be interested in establishing 
that the function divide defined below satisfies its intentions* 


<define divide <function idivide 

;"let idivide be naae of this activation" 

[n d] 

;"the function divide is a function of two arg isents a and d" 

Crepeat [[r .n] [g 0]] 

;"initialize r to n and g to zero" 

;«we are in a repeat loop which will repeatedly 

execute the following expressions" 

<cond 

[<is? <less .d> *r> 

;"if .r is less than .d then" 

<.idivide .g .r> 

;"exit the activation naaed 

idivide with *g and .r"]> 

<assign sr <- .r «d» 
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/l r m \ 

£?- '5 

;"assign r the value of r minus d" 

<assign :g <♦ .q 1» 

;"assign g the value of q plus 1" 

;"now go back and do the body of the repeat 

loop all over again"»> 

He shall express the intentions of the function DIVIDE in a 
goal oriented foraalisa called IHTEHDEB. IHTEHDEB enables us to eased 
the intentions for a program in the text of the program. The easiest 
way to understand IHTEHDEB is to match how it works, in order to 
show how it works we must first define soae intentions. IHTEHDEB 
introduces two new primitives CVEBAIL and IHTEHT to express intentions 
in code. The priative 0VEBA1L expresses the overall intention of a 
function or loop whereas IHTEHT asserts that the intended situation 
really bolds within the body of the function or loop. The meaning of 



IHTEHDEB is a giant sledge hammer to use to squash such a tiny 
problem. The reader can see this sledge hammer used on harder 

problems in chapter 7. IHTEHDEB needs to be able to talk about 

* . . ..... • . ;; . , _ .. . __. ,/ .. ...... .. . . .. ..... . .. 

function calls in a pattern directed way. He will use I* to suppress 
procedural invocations. Thus whereas <♦ 3 5> evaluates to the HOHBEB 
8# the expression !•<♦ 3 5> will evaluate to the CALL <♦ 3 5>. 
Assertions which contain calls constitute a still higher level 
assertion than the two which we have introduced thus far. The 
semantics of such assertions are determined in part by the body of the 
procedure which is called. For example the assertion that !•<* !•<♦ 1 
2> 1,<+ 2 1» can be established from the DEFIHITICH of ♦. Similarly 
in a very incestuous way, we can make assertions about PLAHHEB 
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procedures whose intentions are theaselves written in PLASHES and at 

any given tine constitute the nodel that CLASHES has of itself! By 
using intentions expressed in CLASHES* there is nothing that in 
principle CLASHES cannot be nade to understand about itself. 

<define divide <function idivide [n d] 

Coverall [ ] 

Cintention [] 

Cand 

Cgoal I'Cis I'Cgreater 0> .n» 

Cgoal I'Cis I'Cgreater 0> .d»> 

Cand 

Cassert I'Cis I'Cgreater 0> .n» 

Cassert I'Cis I'Cgreater 0> .d»» 

Crepeat £[r . n] [g 0]] 

!;Cintention 

Cgoal 1 • C* .n .r !•<♦ .g»» 

Cassert I'C= .n t'C* .r t'C* *d .g>»>> 

Cqond 

£Cis? Cless .d> .r> 

C.idivide .g .r>]> 

Cassign ;r C- . r .d» 

Cassign :g <♦ .g 1>» 

Cfunction £C B] 

Cintention [] 

Cand 

Cassert I'C* • n I'C* .B l'<* .d #Q»>> 
Cassert I'Cis? I'Cless .d> .?»> 

Cand 

Cgoal I'C 3 .n I'C* .B I'C* »d 
Cgoal I'Cis? I'Cless «d> .B)»»»» 

The overall intention for the function DIVIDE is that it return two 
values Q and B whicli we assert will have the property that 


!'C=.n !'C+ .B t'C* .d .Q»> 

The inside intent of the function DIVIDE is the goal that DIVIDE will 
return two values Q and B which will have the property that 


l'C*.n I'C* .B I'C* .d .Q»> 
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The body of 01TIDE is a BEPEIT loop with two locals r and g which are 

respectively initialised to 0 and n. The overall intention of the 
REPEAT loop is the goal 

!*<= .n !•<♦ . r !•<* .d ,g>» 

The REPEAT loop has an intent that asserts that 


!*<=.n I •<♦ .r !*<* .d .g»> 
at the top of the loop. 

The intentions for DIVIDE are proved by running then in 
INTEHDEfi. The intentions are verified abstractly. Thus they aust be 
true independent of what the actual argunents to the function are. We 
shall use the notation r_n for the nth value of the identifier x with 
*- being anabbreviation for the initial value of x. The actions of 
INTEHDEH on the intentions of DIVIDE are as follows: 


Proa the overall all intentiion of the function we have: 
<assert !'<is !*<greater 0> n » 

<assert I*<is l*<greater 0> d~» 


loop assertions cone froa the declarations of the 

<assert '<= r_ n_» 

<assert •<* 0>> 

The intention of the repeat stateaent on first entry is 

<goal I»<= 

n 

l"*<* 


r_ 

!•<* d 


_ g_»» 


"assert*! assaM £or th€ repeat loop 


!•<♦ 
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r 1 

!»<* a_ g_i»>> 


enter intenticns of CCHD . , 

There are two cases for the conditional: 


Casel: . _ 

<assert !*<is? 

!'<less d_> 
r_1>> 

Prom the overall intention we have: 
q becomes g_1 
R becocoaes t_1 
<goal !'<= 

n 

1 7 <+ 

r_1 

! • <* a_ q_1»» 

<goal !*<is? !*<less d_> r_1» 


Case2: 

<assert !*<is? 

!*<greater* d_> 


r_ 

1>> 


Proa <assi 

gn :r 

<- .r .d» we get 

<assert !* 

<= 

r_2 

! • <- r_1 d_>» 

Proa <assi 

qn :g 

<♦ . g 1» we get: 

<assert !* 

<= 

9-2 

!•<♦ g_1 1»> 


The recursive goal is satisfied by simplification: 
<goal !»<= 

n 

l 7 <* 

r 2 

!•<* d_ q_2>»> 




4. THE PATTEBN HATCHIH6 LANGUAGE ^ATCLLESS 


MATCHLESS is a pattern directed language that is used in the 
implementation of PLANNEB. HATCHLESS is used both in the internal 

of PLANNEB and as a tool in the deductive system itself. 
HATCHLESS is similar in certain respects to other structural pattern 
matching languages such as CONVERT and SNOBOL. It has been designed 
with the following considerations in mind: 

0. The language must obey the fundamental Principle of Pattern 
Directed Computation: the procedure body should be a pattern that 
describes the purpose cf the procedure. The principle has been 

developed even further in PLANNER where procedures are invoked on the 
basis of their intent. 

1* The language should be very powerful yet simple constructs 
should be efficiently compiled. By incorporating more knowledge into 
a program, it must be possible to increase its efficiency up to the 
limits imposed by the machine on which it runs. 

2. Functions must be able to be separately compiled. 

3. It should not require parsing for efficient 
interpretation. Procedures should be naturally and efficiently 
constructed and edited by ether procedures. 

4. The language must interface with PLANNEB in a natural way 
since it is used as a basic part of the deductive system. Effective 
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problea solving requires a sophisticated prcgraanable Batcher. 

5. The language should treat strings, lists, vectors, tuples, 
and nodes syaBetrically so that for the lost part the saae prograa 
will run whether the structures are Bade up of vectors, tuples, nodes, 
or lists. Declaration* deteraine which fora is actually used. 

6. The language should have no autoaatic coercion. Any 
procedures which wish to coerce their arguaents should be able to do 

so easily. 

7. The language should have only one aode of evaluation for 
value. locatives should always be generated explicitly in the saae 

way. 

8. All the loops of the language should be guaranteed to be 


properly nested 



4.1 The Syntax of Identifiers and Expressions 


HATCH1ESS attempts to obey the Fundamental Principle of 
Pattern Directed computation: the procedure body should be a pattern 
of what the procedure is supposed to accomplish. For example it 
allows the list (a b c) to be produced by simply evaluating (a b c) . 
In attempting to realize the principle me have been led to develop a 
certain amount of syntax vhich (unfortunately!) must be described. 

4.1.1 Prefix Operators for Identifiers 

As is usual in pattern matching languages me shall allom 
constants like 3, a, (a b) , and (e (f g)) to natch only themselves. 

An identifier is indicated by a prefix operator which tells how the 
identifier is to be used. For example .x is the element value of the 

identifier x. If x has the value (a 3) then .x will only match (a 3). 

We need to be able to change the value of an identifier in a pattern 
match. Suppose that x has the value 3. If we natch __x [the 
tentative value of x] against (a b ), then x is given the value (a b) • 

The identifier x will keep the value (a b) if the remainder of the- 

pattern matches. Otherwise the value of x will revert to 3. Again 
suppose that x has the value 3. If we match :x [the altered value of 
x] against (a b), then x is given the value (a b). However the value 
of x will remain (a b) whether or not the remainder of the pattern 
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matches. 

The above prefix operators are actually defined in terms of 
procedure calls. He are not enaaored with the syntax of the prefix 
operators but they are easier to type than the procedures listed 
below. 

A saall Beta syntax is needed in order to give explanations of 
the primitives of the language. He shall use J to deliait 
aetasyntatic variables which are elements and - to deliait those which 
are sequences. 

The following table explains the prefix operators which yield 
element values: 

•1*1 ® <VALUE |x|> the element value of the identifier ]x] 

,lxj = <GLOBAL |x1> the eleaent global value of Jx| 


The following table explains the prefix operators which Batch 
elements: 

?|xj * <GIVEB |x|> will give JxJ the value of the aatching 
element if Jx| does not already have a value; otherwise ?jx| will only 
match the value of ]x 1 • 

:JxJ = <ALTEB!-PEESISTEMT Jx|> will alter the value of x to be 
the aatching eleaent even if |x| already has a value. 

_|x| = <ALTEB!-TEHTATIVE |x1> will tentatively alter the value 
of |x| to be the matching element but if a failure backs up then the 
old value of ]x| will be restored. 
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If x has the value (a 1) then (b .x 4) will evaluate to (b (a 

1) 4). The character I is the escape character. He will use !.x to 
denote the segaent value of the identifier x. For exaaple (b J.x 4) 
will evaluate to (b a 1 4). In each case preceding the prefix 
operator for an identifier will result in the segaent prefix operator 
for that identifier. If we natch the pattern (c !:x d) against the 
value (c 3 a d) then x will be given <3 a) as its value. 

The following table explains the prefix operators which yield 

segaent values: 

l.jxj * {VALUE |x{} the segaent value of the identifier |x| 
1,1*1 * {GLOBAL lx|} the segaent global value of lx( 


The following table explains the prefix operator* which aatch 
segnents: 

j?jx1 * {GIVEN x} will give x the value of the Batching 
segaent if x does not already have a value; otherwise J?x will only 
natch the value of x. 

!:x = {ALTEB1-PEBSISTENT x} will alter the value of x to be 
the Batching segaent even if x already has a value. 

1.1*1 * {ALTEB!-TENTATIVE 1*1} will tentatively alter the 
value of lx{ to be the aatching segaent but if a failure backs up then 

the old value of (xl will be restored. 

Gerry Sussnan and I have developed the following scheae for 
looking up the values of identifiers in interpreted 


code. Os the 





| IDENTIFIER | 
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identifier stack when an identifier is bound the following information 
is stored: 

1. the naae of the identifier 

2. the current value of the identifier 

3. the place on the stack where the identifier was previously 
bound 

Associated with each binding environment and identifier we have the 
place on the identifier stack where the Identifier was last bound. 

4.1.2 Syntax of Expressions 


*6 ■■■** 



MATCHLESS uses Polish prefix notation for function calls with 
the actual call delimited by < and >• Of course we use the characters 
( and ) to delimit lists. He use the characters £ and ] to delimit 
vectors. For example <♦ 2 3> evaluates to 5. If y has the value 4, 
then <♦ . y 1> will only natch 5. The value of (.y) is (4) and the 
value of (<♦ .y 1> (4 a) .y) is (5 (4 a) 4). If the function call is 
to denote a segment then it is delimited by { and }• The function 
BEST will return the rest of the list that it is given as an argument. 
For example <rest (a b c)> evaluates to (b c) • But (1 (rest (a b c)) 
e f) evaluates to (1 b c e f). Furthermore, (a b (rest (1 (e f) g)} 
k) will only match (a b (e f) g k)• The components of lists, vectors, 
and nodes can be selected by subscripting. For example <2 (a b c)> 
evaluates to b and <3 £ (a) e 5]> evaluates to 5. The expression <get 
|i| |z|> will return the location of the |i|th component of the 
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structure JxJ. Other values are computed from patterns. The value of 

C-y l a *y] is £4 (a b) 4]. Tuples are stored in the stack whereas 
the vectors are garbage collected. lexically the scope of a tuple is 
the smallest enclosing pair of < and > or { and }. Otherwise vectors 
and tuples are indistinguishable. An argument of a function may be 
computed in parallel with the other arguments by delimiting the 
argument with |< and > instead of < and >. For example 7+3 could be 
computed in parallel with 2+4 in the expression <♦ J<+ 7 3> <♦ 2 4». 
An argument of a function nB5T be able to be computed in parallel if 
it is delinitted by !j< and >. In other words, if one branch becomes 
blocked the other must be able to continue execution. 


The type hierarchy is: 


<?> for the universal type. 

<WOBD> for priaitve types which are not pointers. 

PALSE for the logical type faisg. All other.data are 
considered to be true in conditional expressions. The null 

function call <> will evaluate to tFALSE. 

CHABACTES for a character such as !"a or !"U. Again we are 
using ! as an escape character. The ! converts " into the 

quote for a single character. 

<NUHBEB> for nuabers. 

<FIXED> for fixed point nuaber. 

FIX for a snail fixed point nuaber. 

BIG for a big fixed point nuaber. 

FLOAT for floating point nuaber. 

<POIHTER> for pointers. 

ATOM for atoas. The following are all atoas: a, foo, and 
hello 

<STBOCTORE> fox structured data. The operations of taking the 
BEST of a structure and selecting the nth eleaent are defined 

on all structures including tuples, vectors, lists, and nodes. 

For soae structures the operations are nore efficient because 

of special hardware. 

TUPLE for a tuple of eleaents. Tuples are allocated froa 
the stack cf a process and are deleted on procedure exit. 

Tuples occupy contiguous blocks of aenory. Once a tuple 

has been created its structure cannot be changed and its 

length can not be increased. 

VECTOR for a vector. Vectors are allocated contiguous 
blocks of storage which are garbage collected when no 

longer pcinted at. Although the structure of a vector 
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cannot be changed, its length can be increased at the cost 
of a garbage collection. Otherwise vectors are identical 
to tuples. 


STBING for a string. 
For exaaple "ba" # "3* 


This is just a vector of characters. 
» and "a b w are strings 


LIST for a list. Lists have the advantage over vectors 
that their structure can be changed after the; have been 
created. The; have the disadvantage that it takes a tine 
proportional to n to get the nth eleaent. 

NODE for a node which has properties. Modes are the aost 
general form of structured data in the language. The 

others are included for reasons of efficiency for 

specialized structures. The components of a node are 

obtained by subscripting which is currently iapleaented by 

hash coding. A vector is approximately one third the size 

of its corresponding representation as a node. 


The following types will not be explained here. They are 

included only fcr completeness. The complicated types and their 
abbreviations are: 

JUNCTION for junction 

ACTIVATION for activation. 

STATE for state. 

ABC for a node arc. 

BIBO for bindings. 

<LOCATI?E> far a locative or generalized location• 

flCTOB—LOCATIVE for a locative to an eleaent of a vector. 
TOPLB-LOCATIVE for a locative to an eleaent of a tuple. 
BINDING—LOCATIVE for a loactive to the value of an identifier 





LIST-LOCATIVE for a locative to an element of a list 

LIST-B1ST-L0CATIVE for a locative to the rest of a 1 
NODE-LOCATIVE for a locative to an element of a cole 

LABEL for a label function. 

PROCESS for process. 

STACK for a stack 
SING for a ring 

ELEMENT—CALL for a eleaent call. 

SEGMENT-CALL for a segment call. 

SEGMENT-VALUE-CALL for a segment value call. 
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4.3 Simple Examples of Hatching 


The idea of structural matching is fundamental to the 
MATCHLESS processor. By means of the primitive function CIS? 

|pattern| |expression!> ve can determine if Jpattern) matches 
|expression|. The function IS has the value true if the match 
succeeds and <> (which is FALSE) otherwise. Pattern matching takes 
place through the use of side effects to change the values of 
identifiers to be those of the objects which they match. The 
assignment statement in MATCHLESS is a variant of the primitive IS. 
The expression <_ (pattern} iexpression|> is well defined only if 
ipattern] matches (expression). The value of the function _ is the 
value of ]expression|• Below we give some examples of matching where 
the values of identifiers are listed after assignment statements have 
been executed. He use the character - to delimit segments. For 
example the list (a b c) has subsegments: 

—t -a- # -a b- t -a b c~, -be-, -b- r and -c-. 

The characters < and > are used to delimit function calls. 

<prog £a [I-atcm h] c] 

;"This is a comment. 

He are inside a program in which we have 
declared a, declared h to be of type atom, 
and declared c" 

;"in the test below 

the function IS will return true 
since the pattern (_a k _h !_c) matches 
the value ((1) k b o a)" 
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<is? (_a k _h !_c) ((1) k b o a)>> 

a gets the value (1) 
h gets the value b 
c gets the value (o a) 

The value of the prograa is true which is the value of the IS 
st ateaent. 


<prog 


[c [S=atcn h] a] 

j^h is of type aton" 

<is? (!_c _h k _a) (a j b k q) » 

c gets the value (a j) 

h gets the value b 

a gets the value g 


<prog [first last aiddlel 

<is? (_first !_ai!ddle _last) (abed)» 

first gets the value a 

aiddle- gets the value (b c) 

last gets the value d 


<prog [a b] 

<is? (_a _b) (d) » fails because there is only one 

eleaent in (d) . 



<prog [£!=atca a]l 

;"a is of type atoa" 

<is? _a (o t)» fails because (o t' is net an atoa. 

An expression that consists of the prefix operator followed by a 
identifier will only aatch an object equal to the value of the 
identifier. 


<prog [a] 

<is? (!_a I.a) (a b c a b c) >> 
a gets the value (a b c) 

<prog [a bl 

<is? (!_a x i.a !_b) (a b x d x a b x d g)» 
a gets the value (a b) 

a failure occurs because (I.a !_b) will not aatch (d x 

a b x d g) 

a gets the value (a b x d) 
b gets the value (g) 

An expression that consists of the prefix operator ? [the value given] 
followed by an identifier Batches the value of the identifier if it 
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has one, otherwise the identifier is assigned a value. 


<prog [a] 

Cis? ?a t» 
a gets the value t 



a is declared to he of type fix and initialized to 5 
on entrance to the prog. Consequently the assignment statement fails. 


Cprog [al 

Cis? (!_a 2?a) (a b c c t a)>> fails because once a is 
assigned a value, a can only match a segment that is egual to the 
value of a. 

The function HATCH? is somewhat more powerful than the 
function IS? because it can match patterns against patterns. 


to 3 


<prog [x y] 

Cmatch ?x ?y> 

;"link x and y by matching them to each other** 
Cmatch ?x 3> 

;**let x have the value 3 and thus set y to 3 W 


• 7 

; H the value of y is the value of the prog”> evaluates 


fiestrictions on the value of an identifier can be acguired as 
the result of a match. 


Cprog [x] 

Cmatch ?x Cless 5>> 

;**x will only match numbers less than 5” 

Cmatch 6 ?x» fails since 6 is not less than 5 

Side effects can propagate through structures: 


Cprog [x y z] 

Cmatch ?x [ ?y !?z3> 

Cmatch (a b c) ?x> 

;"y gets the value a and z gets the value (b c) **> 
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4.4 Definitions of Procedures 


4.4.1 Functional Procedures 


<FUBCTICN 

♦checker* ♦activation-name* [-function-declarations-] 
-expressions-> where ♦activation-name* and ♦checker* are optional, 
will evaluate to a function which will, when it is called, bind the 
foraal paraaetcrs in the 1 function-declarations} to the actual 
parameters, evaluate the -expressions- returning the value of the last 
one as the value of the function. The *checker* aust he of the fora 
<|procedure| -arguaents-> fox one value or {} procedure] -arguments-} 
for multiple values. The *checker* is treated as a pattern that the 
values returned oust natch. The natch is done so that any side 
effects are persistent. The |-function-declarations-} is of one of 
the following forms: 


Jarguments-specification| which may be one of the following: 
[-foraal-paraaeter-specifications-] where each xoraal- 

parameter-specification is of one of the following forms: 

(evaluaticn-specification| where each Jevaluation- 
specification] aust be one of the following: 

*}identifier] means that the (identifier} is to be 

bound to the write protected UNEVALOATEB corresponding 

actual parameter. 


(identifier} means that the (identifier} is to be 
bound to the VALUE of the corresponding actual 

parameter 
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[(attribute-specification) (evaluation-specification) ] 
where the (attribute-specificationJ aust be one of the 
following: 

(attribute| 

[-attributes- ] 

where each attribute aust be one of the following: 
•’"SPKIIl" neans that the identifier nay be usea 

free in other nodules. The symbol -""SPECIAL" is a 

unigue string. 

<I procedure| -argunents-> neans that the 
identifier aust always be either unassigned or 

bound to an object which Batches the pattern 

<(procedure) -arguaents->. The constraint is 

enforced by PLANNEE. Any side effects of Batching 

the pattern against the new value of an identifier 

are persistent. 

t -foraal-paraaeter-specifications- ""OPTIONAL" -optional- 
orsal-paraaeter-specifica tions-] 

where an |optional-foraal-paraaeter-specificatiorI is 
either a jfornal-parameter-specification! or [(attribute- 

specification) [(evaluation-specification( (initial* 

value|]]. The -""OPTIONAL* construct is due to Chris 

Beeve. It alows for optional arguments and specifies how 

the identifier is to be initialized if the actual 

paranater is not present. 

[-foraal-paraaeter-specifications- -""BEST" (identifier- 
specification) ] which will bind the identifier in (identifier- 

spec ificaticnj to the tuple of the rest of the arguaents 

evaluated. 

[-fornal-parameter-specifications- -»"BEST" ' (identifier- 
specification1 ] which will bind the identifier in (identifier- 

specification | to the write protected vector of tne rest of 
the unevaluated arguaents. The * variant is due to Garv 
Peskin. 


[-•"BINE" )identifier-specification( (arguaents-specifcation) 
declarations-3 is used to first bind the identifier in 
(identifier-specification) to the bindings in effect when the 
function ir invoked. In alaost all cases use of -""BUB* can 
be avoided by reading the function into a local syntactic 
block so that no identifier conflicts can occur. 




[-*"P1T7EII" | calling-pat tern I |arguments-specifcation|] 
defines a calling pattern for pattern directed invocations. 
The calling pattern is of the forn [-declarations- 1 pattern|] 
which declares identifiers for Jpattern!. 


Por example: 


«fanction [-»"rest" x] <2 .x» 11 21 33> evaluates to 21 

since <2 [11 21 33]> is 21 


«function [-»"rest" *x] .x> 

a 

<♦ 3 4> 

c> evaluates to [a <♦ 3 4> c] 

«function [x] .x> 3> evaluates to 3 
«function [x] .x> a> evaluates to a 

«function !=fix [[!*fij x]l .x> <♦ 2 2» evaluates to 4 where 
!=fix is <0F—TXPE fix> 


«function !*fix [[!=fix x]] <♦ .x 1» 2> evaluates to 3 

«function l=fix [[ !=£ix x] [ J=fix y]] <+ .x .y>> 2 3> 
evaluates to 5 


«function [x optional" [y 3]J <♦ .x .y» 4> evaluates to 7 
«function £x -»"optional" [y 3]] <♦ .x .y>> 4 5> evaluates to 


«function [[!*fix *x]] .x> 3> evaluates to 3 
«function [*x] .x> a> evaluates to a 
«function ["x] .x> <♦ 2 2» evaluates to <♦ 2 2> 

8e would like to give a sinple example of pattern directed 
invocation. Suppose that we have a sink s which we need unstopped. 
The classical solution is to know the naae of a plumber which could be 
applied to the sink. Thus for example we might evaluate <piumber- 
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Perlnan s>. The way we shall actually proceed is to advertise that we 

need a sink unstopped. Of ccuse we won’t let just anyone work on our 
sink; he must cone well recommended. For example he should be cheap 
and speedy. He will evaluate 


Ccall 

£<[unstop s] $5> 

<speedy>]> 

to offer to let some oie unstop our sink for $5 provindisg he is 
speedy. How suppose that there are a few plumbers around: 


<define plumber-Greentlatt 

<function 

£ -'"pattern" 

££sink] £ unstop ?sinkl] 
fee ] 

<cond 

£<is <less $4> .fee> 

<fail> ]> 

if the fee is less than $4 
then fail" 

<Hoto-Booter «sink> 

;"otherwise apply Boto-Rooter 

to the sink"» 


<define plumber-Perlman 

<function 

£-'"pattern" 

££sink] £ unstop ?sinkj] 
fee] 

<pour Drano .sink> 

•"pour Drano in the sink" 

<send-hill <times 2 .fee» 

;"send a bill for twice the originally 

agreed fee"» 

To try to get our sink unstopped we night evaluate; 


<prog £] 

<call 


[<£unstop s] $5> 
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<speedy> ]> 

;"advertise for a speedy plumber to 

unstop sink s for $5" 

<ccnd 

[<stopped-up? s> 

<fail> ]> 

; N if the sink is still stopped up 

then try again w > 

Suppose that both plumber-Greenblatt and plumber-Perlman are 
classified as speedy. Thus P1ANHEB will chose one or the other to 
invoke since both have patterns which Batch the calling pattern 
[unstop s]. If either one fails then the other will be tried. If one 
returns but the sink is still unstopped when he gets back then the 

ness the first created will be undone and the other tried. 

■ . : ~ ..... 

He can define the function reverse which returns a newly 

constructed reverse of its argument as follows: 


<define reverse <function [x] 

<rule [ ] .x 
J[<empty> 

.x] 

[<structure> 

«storage ,x> [reverse <rest . x>) <1 .x»j 
■'•"else” 

<error>»> 

Thus <reverse [a [b c] 4J> is [4 [b c] a]. 

Functions with an arbitrary number of argunents are 
acconaodated by passing a tuple which contains the evaluated 
arguments. Suppose that we already have a function PLOS which will 
add two numbers together. 
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<define + <function pi 

;"let the naae of the current activation be pi* 

[-•"rest” x] 

;"we will receive a variable nuober of 

arguaents in the tuple x" 

<f or 

[[result 0] n] 

;"initialize the identifier result to 0" 

[[-."test" 

<is? [] .x> 

<.pl .result> 

;"exit .pi with .result" 

;"each tiae before executing 

the loop test to see 

if x is a null tuple and if so then 

return the result"] 

[-."step" <chop x>] 

;"after each pass through the loop chop x by 

assigning x to the rest of x"] 

<_ : result <plus <1 .x> .result» 

;"the body of the loop is to add the first eleaent of 

x into the result"»> 


<♦ 3 (rest (4 5 6)} 7> evaluates to 21 
<♦320 evaluates to 9 


<ACTGB-FUNCTIGK 

[{object] |tailj {locative} {choice] -function- 
declarations-] -body-> is exactly like the function FOMCTIOH except 
for the folowing: 

It is treated as an actor in pattern Batching. 

The first arguaent Jobject] is the Batching object. 

The second arguaent |tail| is a tail of the Batching object or <> 
for an eleaent call. 
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The third argument |locativel is a locative to |object| or <> if 
none such exists. 

The fourth argument jchoicej is not false only if the actor- 
function gets its choice hew much to match. 

The value of the actor-function is the rest of the object yet 

to be matched. Actor functions are useful as in internal interface 

between actors and functions. 

4.4.2 Macro Procedures 

Macros are expanded by the interpreter and by the compiler. 

The results are respectively interpreted and compiled. Macro 
procedures look like 

<MACfiC 

{formal-parameters} -expressions-> The expansion of 
the macro is the value of the last expression. The character !• is 
used to suppress invocations. For example whereas <♦ 2 2> evaluates 
to the NUMBER 4, !•<♦ 2 2> evaluates to the function call <♦ 2 2>. 

<define choploc Cmacro [*x] 

! *<putloc 

• x 

!'<rest !»<in .x»»> 

The macro choploc will take a location as its argument and cause the 

contents of that location to be changed to contain the rest of the 
previous contents. 

<choploc <at y» expands to <putloc <at y> <rest <in <at y»» 
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He could have defined the function ♦ as a macro as follows: 


<define ♦ <aacro {•'"rest" ’x] 

;"let x be the vector of unevaluated arguments" 

<rule ,x 

[<empty> 

;"if x • is <♦> then the answer is 0" 

0 ] 

♦declare 
[[first rest] 

;«declare identifiers first and rest** 

[sfirst !:rest] 

{"otherwise let first be the first argument and 

rest be the rest of the arguments" 
!*<plus .first ! *<♦ !.rest» 

;"the answer is written out using 

binary plus instead of + "]»> 


Thus 


<♦ 3 2 4> expands to <plus 3 <plus 2 <plus 4 0»> 


4. 4. 3 Actor Procedures 


Actors are used in patterns to match values. The primary 
difference between functions and actors is that functions produce 
values while actors match them. Actors and functions take their 
arguments in an exactly analogous fashion. Examples of actors are 
found in section 4.5 below. 

<ACTOB 

♦checker* ♦activation-naae+ |function-declarations) - 
patterns->, where +activaticn-name* and ^checker* are optional, 
evaluates to an actor which when it is invoked, matches an object 
which matches all of the -patterns- after the identifiers in the 
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|function-declacationsj are bound. The |function-declarationsj is 
interpreted EXACTLY as in FUNCTION. 

«actor [-•"rest” x] <2 .x» 1 a 3> Batches only a 

«actor [-»"rest M 1 x] <2 . x» a <♦ 3 4> c> Batches only <♦ 3 4> 
«actor [x ] .x> 3> Batches only 3 

«actor [x] .x> a> Batches only a 

«actor !-fix £f!=£ix x]] .x> <♦ 2 2>> Batches only 4 where 
!=fix is <0F-T1PE fix>. J 

«actor !*fix [[ !=fix x]] <♦ .x 1>> 2> matches OBly 3 

«actor !=fix ££!=fix x] [!=fix y]] <♦ .x .y>> 2 3> matches 

only 5 

«actor [£ !=fix *x]] .x> 3> Batches only 3 

«actor £*x] . x> a> Batches only a 

«actor £*x] .x> <♦ 2 2» Batches only <+ 2 2> 

4.4.4 Type Procedures 

Type procedures are used to define new types. New types can 
be defined by the union* direct product* and direct sub of already 
defined types. Types can also be defined as procedures by patterns. 

<de£ine empty <either () [ ]» 

Define espty to be either an eapty list [) or an eapty vector 
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<define aonadic <either <nunber> I =atoa <eapty»> 

Define the type aonadic to be a nnaber or atonic or an eapty 
structure. 

<define property-list <actor <list> [] 

<star (l^aton <?>)>» 

A property list is a list of two element lists whose first eleaents 

are atonic. The actor STAfi is the Kleene star of regular expressions. 
For exaaple the following are property lists: 0, ((a (3)))« and ((pi 
4) (hello (r 3))). 

4.4«4-1 Union of Types 

<EITHEB 

-alternative-types-> is a type which aust be one of 
the alternative types. For exaaple we can define the type <nuaber> to 
be the either <fixed> or the type of float. A disjunction of types 
expresses a constraint on what can be considered to be of the new 


<define nuabar <either <fixed> !=float» 


<prog rr<nuaber> [x 3]]] 

; M x is declared to be of type <nuaber> and 

initialized to 3" 


<cond 

[<is? !=fix .x> 
yes ]» 

evaluates to yes since x is really the of type fix 








4.A.4.2 Product of Types 


<fBODOCT 

|type-naae| (kind! Jforsal-parameters| -projection- 
specifications^ will create a type with naae jtype-naae! aade out of 
(kind! storage with Iforsal-parameters! as for functions and - 
projection-specifications—. Each Jprojection-specificationl sust be 

of the following fora: 

£ Iapparent-projector-nasesl [(initial! lpat|] ♦checker* 
(actual-projector!] The Japparent-projectors-uaaesl is either 
a single projector naae or [Jidentifierj (list-of-projector- 
naaes|] where (identifier! ranges over |list- of-projector- 
naaesl. If ^checker* is present then only objects which 
natch ^checker* can be stored in the conponent. When an 
instance is constructed, the elements are given the value 
(initial!. Ihen an instance is decoaposed, the pattern Ipat) 
is used in Hatching. If only Jinitial| is given then |pat| is 
assuaed to be the sane as |initial|. If the actual projector 
is not specified then the next unused integer projector will 
be used, in actual projector which is a procedure call gives 
rise to a VIETDAL projector storage for which is not 
necessarily physically present in the data structure. A 
product type can be BETBACTED to the (kindl of storage out of 
which it was constructed. The function PBCDUCT grew out of 
soae discussions that I had with lick Pippinger. 
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<define cooplex 

<product complex vector £r i] 

[real [.rj <numfcer>] 

[imaginary [.i] <number>]>> 

The type coupler (for coupler number) is the direct product of type 
<number> with projector real and type <number> with projector 
imaginary. The object complex is actually two procedures: a 
function which is the constructor and an actor which is the 
decomposer. Constructor-decomposers implement the overlap of 
functions and actors. 


<complex 3 4> evaluates to fcomplex £3 4] where # is the type 

marker 


<retract <complex 3 4» is £3 4 3 . 

* 4 . 1 . <getc real <complex 3 4>> (which computes the real component 
of the complex nuaber 3+4a) evaluates to 3 * 

<getc imaginary <ccapler 3 4» evaluates to 4 

<prog [£<number> a b]l 

;"This a ccmment. Ve are 

inside a program. The identifiers a ani h are 

declared to be numbers'* 

in the assignment statement below 

the pattern <coaplex __a _b> is matched 

against the expression fcoaplex £3 4 ]** 

<_ <complex _a _b> Ccciplex 3 4»> 

a gets the value 3 ” 

b gets the value 4 

<getc real 

<_ 

Cccmplex <replace 7> 4> 

<ccaplex 3 4»> evaluates to 7 

<prog [[!=complex [c <complex 1 2>111 

<getc real .c>> evaluates to 1 

ie need to be able to get at the locations of the components of a 
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product. The <getc 1 projector| J structure J> is used for this 


purpose. The expression <PDTLOC |1J jz|> sets the location |lj to 


the value |x] and return the value )x]. 



<putloc 


<getc 

2 > 


real 


to Icomplex £3 
.x> 


4]" 


;"x now has the value #conplex [2 4]"> 

He can define a lower triangular natrix initialized with zeros 
as follows: 



<define triangular <product triangular vector £n] 

£i <thru 1 .n>] 

[ 

<ivector .i <function £j] 0» 
;"each coaponent is initialized to 
a zero vector of length i" ] 

<ivector .i> 

; N each coaponent oust be a vector 

of length i"]» 

<triangular 1> evaluates to itriangular £[011 
<triangular 2> evaluates to itriangular f t C j [0 0]J 

<2 <triangular 2» evaluate to £0 0] 

He can define the type PDP-10 instruction as follows:" 


<define instruction <product instruction fix 

[op acc indir index addr ] 

[opcode [.op] !*fix <bits 9 27 > ] 

[accumulator [.acc] !=fix <bits 4 23>] 
[indirect [.indir] !=fix <fcits 1 22> ] 

[index [.index] !=fix <bits 4 18>] 

[address [.addr] !=fix <bits 18 0> ]» 

A PDP-10 instruction has 9 bits of opcode which are 27 bits froa the 
right end of the word, 4 bits for accuaulator number, 1 bit to 
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indicate indirection, 4 bits for index register nuaber, and 18 bits 

for an address. An instruction with opcode 172 and 4 in the 
accumulator field causes the nachine to halt. le can construct such 
an instruction with instruction 172 4 C 0 0> which evaluates to 
instruction 254400000000 in octal. 

The next exanple illustrates the use of virtual components. 


<define aobjp-ptr 

<product aobjn-ptr fix 
[1 a] 

[length 

£. 1 ] 

!»fix 

<signed-bits 18 18>] 

£ address 

£.a] 

I =f ix 

<bits 18 0>]» 

On a POP-10 an aobjn pointer is is word whose left half 
contains the negative of the length of the rest of a vector and whose 
right half is the address of the eleaent of the vector pointed at. 

The trailer is a virtual component which lies just after the vector. 
It can be defined as follows: 


<define trailer <function [x] 

<get 

<♦ 

<getc address *x> 
<- <getc length . 
1 > 

<getc address . x»» 


<TIPE—VECTOR 


-eleaent-specif ications-> constructs a type-vector 
where each eleaent specification is of the fora £Jtype| ]value|] which 
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initializes the apparent coaponent )type) to Jvalue|. 


<getc fix 

<type-vector 

[float "above"] 

[fix "below"}» evaluates to "below" 


<CHARACTEB—VECTOR 

-eleaent-specifications-> construct a character-vector 
where each elenent-specificaticn is of the fora [|character| lvalue) ] 
which initializes the apparent coaponent ]character) to lvalue). 


<putc 

<character-vector 

[I"a beginning ] 

[ !"z end 3> 

[I"a very-beginning ]> 
evaluates to 

♦character-vector [[!"a very-beginning3 [!"z end33 



4.4.4.3 Extension of Types 


lie need to be able to extend the types of values without 
otherwise altering then. For exaaple 3 oranges are not the saae as 
the fixed point nuaber 3. 

<EXTENSIOH 

Jtype-naae) |aade-of|> will create a new type |type- 
naae) which is an extension of ]aade-of). Re can define the type 
oranges by 

<define oranges <extension oranges fix» 

Row <oranges 3> evaluates to ioranges 3. 



CUNEXTEHD 




DIRECT PRODUCT CONSTRUCTION 


CCOMPLEX > 



<NUM > 


DIRECT SUM CONSTRUCTION 

<FRU IT> 



<FIX> <FIX> 
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ltype-namej> returns the nane of the type of vhich 
| type-name] is an extension. Thus <unextend oranges> evaluates to 
fix. 


Individual eleients cf a given type can be retracted by the 
function BETBACT. 

<retract <oranges 3>> evaluates to the fixed point number 3 

Similarly we can define apples by 

<define apples <extension appl fix>> 

Then ve can define fruit as the union of apples and oranges. 

<define fruit <either !=oranges !=apples>> 

<oranges 3> evaluates to ioranges 3 which is a <fruit> 

<♦ <oranges 3> <apples 4» is an error because you can*t add 
apples and oranges! To aaa apples and oranges the function ♦ must be 

redefined in a local lexical block. 

<is? <fruit> <oranges 3>> is true 
<is? <fruit> 3> is <> (which is FALSE) 

The actor <AS I pattern] |injector|> will be defined to match 
an object ]obj| only if |obj) is of the type of the range of 

linjector] and ]patternj matches <BETBACT ]obj|>. 

<prog £!=fix org] 

<is? <as :org oranges> <oranges 3>>> 
org gets the value 3 

<is7 <as 4 apples> <oranges 4» is <> (vhich is FALSE) 


4.4.4.4 Direct Suns 
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functions: 

<SET—ALABH 

]identification| 

]tine| 

Ihandier| 

|process—to-be-interrupted J> 

will set an alarn with (identification! which will go off after |tine] 

interrupting |process-to-be-interrupted| with Ihandier]. 

<0HSET—ALABH 

(pattern-for-identification] 

]pattern-for-tine|> 

unsets all alarns whose identification Batches |pattern-for- 

identification] and whose tine Batches |pattern-for-tine]. 

<SET-TIHEB 

|process] 

jidentification| 

jrantine] 

jhandler 1 

|process-to-be-interr upted]> 

sets a tiner for |process] with (identification! which will go off 

after |runtine| interrupting |process-to-be-interrupted! with 
Ihandier]. If (process] is <> then the tiner counts the tine used 
for all processes. 


<0BSE1-TIHEB 

(process) 

|pattern-for-ideatification| 

|pattern-for-runtiae|> 

unsets all the tiners for (process] whose identification Batches 

|pattern-for-identification) and whose runtine Batches Ipattern-for- 
runtine]. 
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4.5 Functions in Expressions 

4.5.1 Definitions of Functions 

Exaaples of the values of various expressions are given belov: 
a evaluates to a 
(a b c) evaluates to (a b c) 

<♦ 1 2> evaluates to 3 

[3 {rest (a c)) ] evaluates to [3 c] 

(a b <♦ 2 3>) evaluates to (a b 5) 

(a b {quote (a b)}) evaluates to (aba b) 

If a has the value 3, then {[ (.a) ] b) evaluates to ({ (3) ] b) 

4.5.1.1 Control Functions 


4.5.1.1.1 Conditional 


<0HFAISE 

|x|> is the value of )x| if it is not false and fails 


<defin« unfalse 

<function [x] 

<cond 

[.*3 

{-•"else" <fail>]>» 


othervise. 
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COB? 

-dis juncts-> evaluates each of the disjuncts in turn 
until one of then is not false in vhich case it is returned as the 
value of the function OR?. Otherwise the value of the function OR? is 


IXCblcck (Coblist orI-> Coblist>) > 

Cdefine or? <function out [-•"rest” 'a] 

Crepeat [[v <>]j 

Ccond 

[Ceapty? .a> 

C.out ,v>]> 

<_ : v Ceval <1 ,a>» 

Ccond 

[•v 

C.out .v>]> 

Cchop a»» 

IXCend-block> 

COB 

-disjuncts-> is exactly like OB? except that if none 
of -disjuncts- is not false then a si is pie failure is generated. 


IXCblock (Coblist or!-> Coblist>)> 

Cdefine or 

Cf unction [-»"rest" «a ] 

Cunfalse Cor? !.a>»> 

!XCend-block> 

CARD? 

-conjuncts-> evaluates each of the ccnjuncts in turn 
unless one of thea is false in which case it returns the value false. 
Otherwise it returns the value of the last conjunct. 
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!%<block {Coblist and!-> <oblist>)> 

<define and? <function out forest" * a] 

<repeat £[v -•"true"]] 

<cond 

£<enpty? .a> 

<.out .v>]> 

<_ : v <eval <1 .a»> 
<cond 

[<not? .v> 

<.out <» ]> 
<chop a>»> 


!%<end-block> 


<AND 


-conjuncts-> is exactly like AND? except that if one 
of the -conjuncts- is false then a staple failure is generated. 


!%<block (<oblist and!-> <oblist>)> 


<define 

rtf: 


<function £-"rest" ’a] 

<unfalse <and? !.a»» 


!%<end-block> 


<HOT? 


|x|> is true if lx| is false and otherwise |x|. 


<define not? 

<function [x] 

<cond 

[.* <>3 

[“•"else” -*"true"]»> 


1 x|> is true if Jx| is false and fails otherwise. 


<define not 

<function £x] 

<unfalse <n'ot? .x»» 


<BCT 
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<CGND 

♦checker* ♦activation-name* -clauses-> is the 
conditional statement of the language. Each clause is of the form 
[predicate -body-] or cf the form #DECLABE [[-declarations-] predicate 
-body-]. The predicate of each clause is evaluated in turn until one 
of them is not false. Then the rest of the elements of the clause are 
evaluated in turn with the value of the last element being the value 
of the function COND. If all the predicates are false then the value 

of the function CCBD is false. The function COND is due to John 
HcCarthy. 

<cond [<> 5]> evaluates to <> 

<cond [<> 5] £-»"else" 6]> evaluates to 6 
If the operator | is used in fron of a clause then the predicate of 
the clause may be evaluated before or after the predicate of the next 
clause or in parallel sith it. The first predicate to converge to 
anything other than false sins the race. There are obvious timing 
errors in the indiscriminate use of | for clauses 

<cond ][ 3 a] £4 h]> evaluates to either a or b 

<CATCH 

♦activation-name* 

£-declarations-] 
lx] 

[IkI -»"tupi,e" | v i ] 

-body-> 

establishes a catchpoint and then attempts to evaluate jx}« If the 

evaluation of |x| comes back sith an abnormal exit then the catchpoint 
is removed, |k| is bound to the type of exit and -body- is evaluated. 

If control runs off the end of -body- then the abnormal exit is 
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restarted. The abnormal returns which are currently defined are of 
the following argument tuples: 


r -"RESTCBE" |activation| -values-1 for a restoration of the 
railpoint |activation! with -values-. 

r-"EXIT-CALL" If 1 largumentsl 1 for a non.local exit call of |fj. 
The expressions jf| may be either an activation or a junction. 

[-"EXIT" |activaticni lvalues! ] for a non local exit to 
(activation! with -values-. 

[-"AGAIN** jactivationj ] for a non local reiteration of 
(activation|. 

[-"TEBHINATE" ] fcr a termination of the process 
for example 


<prog [ ] 

<prog foo [] 

<catch { ] 

<.foo 3 a> 

;*’exit .foo with 3 and a" 

[k -"rest" v] 

<cond 

[<is? .k -"exit"> 

<.bar 

<print 

(caught 

exiting 

with 

• v)» ]»> 

4> 

prints (caught exiting with [3 a]) and then evaluates to 4 

<♦ 

<catch [ ] 

4 

[k -"rest" v] 

<cond 

[<is? .k -"fail"> 

<print "you can’t get here!">]» 

<print 5> 

<fail» 

prints 5 and then fails without printing anything more. 





4.5 page 96 


<c at ch [ ] 

<♦ <print 4> <fail>> 

£ k -* "rest M v ] 

<cond 

[ <is? .k -»"f ail"> 

<print (caught failure)>3» 

will print 4, print (caught failure), and then continue failing. 


<FAILPOINT 

♦checker* 

♦activation-naae+ 

[-declarations- ] 

]expr) 

[♦messag* +activat ion+] 

-body-> 

establishes a failpoint and then evaluates JexprJ. If the evaluation 

does not produce a failure then the value of the function FAILPOINT is 
the value of JexprJ. If the evaluation of ]expr| or soae subsequent 
evaluation ultimately fails back to the failpoint then the failpoint 
is disestablished, the identifier |messageJ is bound to the failure 
message, the identifier Jactivation) is bound to true if the failure 
is to a higher level activation, and -body- is evaluated. 


<failpcint £] <fail> £n a] 

<print hello>> 

prints hello and then restarts failing 
<failpcint £1 3 fn a] 

<print 4>> evaluates to 3 but if a failure 
ever backtracks to here 
then 4 will be printed. 

<prog foo 

<failpoint £ ] 9 £m a] 

<.foo a> 

;"exit .foo with a"> 

<fail» evaluates to a 


<RESTOBE 

|activation] -values-> will restore the failpoint 





4.5 page 97 



naaed by Jactitationj and exit it with -values-. It is an error if 

Jactivationl is not the activation of a failpoint. The function 
BESTOBE is due to Drew HcDeraott. 


<prog way-out [£a 3]] 

<print 

<failpcint out £ ] .a [a a] 

<cond 

£<is .a 5> 

<• way-cut .a>] 

£-«"else" 

<restore • out • a> ]»> 

<inc!-persistent a> 

<fail>> initializes a to 3, prints 3, 
increaents a to 4, fails back into the failpoint, restores the 
failpoint, prints 4, increaents a to 5, fails back into the failpoint, 
and finally exits .way-out with the value 5. The following function 
does not represent good progressing practice and is not original, but 
it dees illustrate the use of BESTOBE. The function <CHANCES 
Jidentifierl |exceeded|> will decreaent the value cf Jidentifierj each 
tiae a failure propagates through it until the value of |identifier] 
becoaes less than or equal to aero at which point |exceeded! will be 
evaluated. 


!%<block (<oblist chances!-> <oblist>)> 


<define chances . „ , ,.. „. 

<function [*i •'"optional” £ *e 

<failpoint f £ ] <> [-• 

<_ :.i <- -,i 

<cond 


C 

[ 


<eval 



•<error>]] 
optional" ] 
1 » 


= 0> ..i> 

.e>] 

re . f . * i> ]»» 


!X<endblock> 


<B0LE 

♦checker* ♦activation-naae* £-declarations-] |x| - 
clauses- —»"ELSB"- -nct-found-> where the +activation-naae* and 
♦checker* are optional gives a rule for the expression ix|. Each 
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clause is of the form [Jpattern} -body-] or of the fora fDECLARE £[- 

declarations-] |pattern| -body-]. The value of |xj is matched against 
the pattern of each clause until a match is found. If there is only 
one element in the clause then the value of the function BOLE is <> 
which is false. Otherwise the value is the value of the last element 
of the clause. If none of the patterns match then the value of the 
function BOLE is the value of -not-found- if it exists or is <> (which 
is FALSE). If a clause is preceded by J then the Jpattern) of the 
clause may be matched against Jxl before or after the pattern of the 
next clause or in parallel with it. If more than one |pattern| 
matches then the first one to natch wins the race. 


<rule [] 3 [!=fix]> evaluates to <> which is false 
<rule [x] a [_x (.x .x) ]> evaluates to (a a) 

<rule [] c (d e ]> evaluates to <> 

<rule £] h £1 a] (h b] [3 c]> evaluates to b 

<rule £ ] <- 3 1> [l b] (<♦ 1 1> c] -."else" 5> 

evaluates to c 

<rule £] a [b 3] -."else" 7> evaluates to 7 

<rule £ ] a £b 3]> evaluates to <> which is false 

Crule £ ] 5 |£<greater 3> "big"] £ dess 7> "snall"]> 

could evaluate to either "big" or "small". 


4.5.1.1.2 Block 


<DECLABE 

-declarations-> declares new top level local 
identifiers within the process which calls DECLABE. It returns a list 
of the identifiers declared. 
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<ACTCS-CALLEB 

lobjectJ 
|tail | 

|locative 1 
|choice| 

|pattern] 

|bindings-for-patternJ > 

enables functions to call the pattern Batcher to latch lpattern) 
against objects efficiently in special cases. 

<CAL L 

1junctron-nane) 

[<]f| -send-args-> |state-path-for-f) IrecoBBendation 

for-f1 ] 

l g I > 

binds the identifier ]junction-nane] to the junction defined by CALL 
and then calls |f| with the specified argunents. The expression ]f| 
aay be any of the following: 

a label function which will be invoked. 

a process which will be resuned. 
a function which will be invoked, 
a port in which -send-args- will be gneued. 
an activation which will be exited, 
a junction which will be invoked. 

a pattern which will atteapt a pattern directed invocation 
The reconaendation Bust be of one of the following forns: 

["•"USE* -pats-*] says that function which Batches one of the 
patterns -pats- BUST be used. 
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[-.«TBY" -pats-] sas that the functions which Batch the 
pattterns -pats- are be tried. 

[-•"FILTER* JhJ] syas that the functions 

< 1 h | 

<CABDICATES FUNCTION |f| Jstate-path-for-f|» 

are all to be invoked (possible/ in parallel)• 

An ordinary function call <|fJ -args-> is equivalent to 


<CA1L 

<|f| -args-> 

<FtJNOTION £ y ] ,y» 

where y is arbitrary identifier. The fora of the argument |g| as a 
function is due to Jerry Sussaan. However* if |g] is of the fora 
[Ifunction] Jstate-path] then it allows for a pattern directed 
resumption through |state-path|. He can define a function idivide of 
n and d which returns the quotient and remainder of the integer 
division of n by d. 


<define idivide <function idivide £n d] 

Crepeat 

[£r .a] [q 0]] 

Ccond 

£<is? <less .n> .r> 

<.idivide .q .r> 

;"exit .idivide with .q and .r"]> 

<_ it <- .n .r» 

<inc q»» 

How if we evaluate 

[a ! (idivide 7 31} b] evaluates to [a 2 1 b] 

<call 

<idivide 7 3> 

<function £a b] 

<print .a> 

<print ,b>» prints 2 and then prints 


1 
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<C ALL 

|junction-namel 
<1f| -arguments-> 

19 1 

Istate-path|> 

where |£| is a label procedure exits tc the level where the label 

function |fj is defined and then invokes jfj with the specified - 
arguments-*. The expression <Jf( -arguments-> is an abbreviation for 


<CALL 

<1f! -arguments-> 

<FUNCTION OUT [-"TUPLE" I] <.0UT !.!»> 

Label procedures and junctions are generalizations of labels. Label 
procedures are defined using the "•"LABELS' 1 construct in block 
declarations. See the example under PBOG. The function )g1 is 
applied to the values received if the process which calls CALL is 
resuned. Executing <.1 junction-name1 -send-args-> will exit to the 
level where (junction-name| was defined and then invoke <1g| -send- 
args->. If the optional argument ]g| is not present and (f| is 
defined in another process then the process which calls CALL is 
terminated. 

<TEKPOBARI 

|junction-nameJ <|f| -arguments> ]gl> makes a CALL to 
jf] such that all the tentative side effects within the scope from the 
point of the call to the exit of )f( are undone. 


<prog [[x 033 

<tenporary 

«function [ ] 

<_ _x 4> 

;"tentatively set x to 4"»> 
;"x is restored to 0 because the 
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call vas temporary* 

. x> evaluates to 0 

<TEHPOBIZE 

(activation] -values-> exits |activation| with - 
values- undoing all the tentative side effects within the scope of 
]activation]. 


<prog {[x 0]] 

<prog out £] 

<_x 4> 

;"tentatively set x to 4" 

<tenporize .out> 

;"exit the activation .out undoing all 

the tenative actions in 
the scope of the activation"> 
,x> evaluates to 0 


<prog 


(£ * 0 ] 

labels" 

[f <function £ ] ,x>] 

;"define t to be a label 

function of no 
argunents that returns the 
value of x ] 

<_x 4> 

;"tentatively set x to 4" 

<tenporize .f> 

;"invoke the label function .f 

undoing every thing which 
is tentative that has been done since 


vas defined"> evaluates to 0 


<prog 




ont 

< 

<function £w] 

<_ _x .v> 

<tenporize .out .x» 
4> 

<function [yj 

<print .x> 

<print . y»» will print 0 
and then print 4 
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<STBAIGH?BH 

<|f| -arguaents» aakes a CALL to |f| suck that a 
siaple failure will sot be caught withia the scope froa the poist of 
the call to the exit of 1ft. The function STBAIGHTSB grew out of 
discussions that I had with Jeff Hill and Terrj Binograd. A very 
siailar concept is called "fast back" in parsing graanars. The 
expression Is}fora| is an abbreviation for <STBAXGBT£B |fora|>. 


<prog £[a 3] b] 

<_ 

<vel _a _b> 

4> 

<print .a> 

<cond 

£<is? .a 4> 

<f ail> ]> 

.b> assigns a the value 4, prints 4, falls 
back inside vel, restores a to have the value 3, assigns b the value 
4, prints 3, and then finally evaluates to 4. 

<prog [[a 3] b] 

!s<_ 

<vel _a b> 

4> 

<print .a> 

<ccnd 

£<is? .a 4> 

<£ail> ]> 

•b> assigns a the valoe 4, prints 4 r falls 
back through _ since it has been straightened but restores a to have 
the value 3 in the process, and thus the whole prog fails. 

<STBAXGBTEH-OP 

lactivation)> straightens the investigation by setting 
up a failpoint which will ccnvert a staple failure into <?AIL 
1activation|>. 
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<define sttaighten-up <£unction [activation] 

Cfailpoint .activation 
[nessage activa] 

<cond 

[<not? <or? . nessage ,activa» 
<fail <> .activation> ]>»> 


<PEBSISTENT 

|junction-naae) <J£| -argunents> Jg|> takes a CAIL to 
|£| such that all changees within the scope fcon the point o£ the call 
to the exit of |£| ace persistent. That is they will not go away 
autoaatically by backtcacking. The expression !piforal is an 
abbreviation for <PEBSISTENT |£ora|>. 


<prog out [[a 3] b] 

<£ailpcint [] <> [a a] 

Ccond 

[<is? .a 3> 

<.out "win">] 

[-•"else" 

<print [a changed to .a]> 

<•out "lose">]» 

<_ <vel ^.a _b> 4> 

<print .a> 

<fail» initializes a to 3, tentatively alters 
a to 4* prints 4, fails back inside vel, restores a to 3, tententavely 
alters b to 4, print 3, fails back to the failpoint, notes that a is 
still 3 and so exits the activation .out with "win". 

<prog cut [fa 3] b] 

<failpornt []<>[» a] 

<cond 

[<is? .a 3> 

<.out *win , *>] 

[-."else" 

<print [a changed to .a]> 

<.out "lose«>]» 

!p<_ <vel _a _b> 4> 

<print .a> 

<fail» initialized a to 3, alters a to 4, 
prints 4, fails back into the failpoint, notes that a is no longer 4, 
and so sexits the activation .out with "lose**. 
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<IS? 

IpatternJ Jexpression) ]is~tablej )is-apply-table)> is 
true only if |pattern| matches the value of 1 expression). The lis- 
table) must be a TYPE-VECTOR and so must the )is-apply-table)• The 
function IS matains two lccal identifiers TABLEI-IS and APPLI-TABLE!- 
IS which are respectively bound to jis-tablej and |is-apply-table|. 

<IS 

1 pattern] Jexpression) iis-tableJ |is-apply-table|> is 
true if jpatternl matches the value of |expression| and generates a 
simple failure otherwise. 


|pattern) Jexpression)> is an assignment statement 
The value of the function _ is the value of (expression). 

Cblock (<oblist assign!-> <oblist>)> 


<define 


Xf unction [‘pattern value] 

<eval !*<is .pattern 
•value>> 


value» 


<endblock> 


<HATCH? 


Jpatternl] |pattern2|> is true if jpatternl) matches 
|pattern2) and is false otherwise. 

<HATCB 

Jpatternl) |pattern2)> is true if )pattern1| matches 
Jpattern2] and generates a simple failure otherwise. 


<EVAL 
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lx I |b| Japply-tableJ> evaluates |x| using the 

bindings ib| to look up the values of identifiers and iapply-table| to 
apply objects according to their types. The lapply-tablej nust he a 
TIPE-TECTOH. The function EVIL naintains local identifiers T&BIB!- 
EVIL and APPlY-TABLEl-fcRAl to hold the current jeval—table! and 
Japply-table| respectively. 

<QOOTE 

|xl> is ]x|. Ve nay abbreviate <QOOTE Jx|> as *|x|. 
For exaaple <prog ££x 1]] •<♦ .x 5» evalutes to <+ .x 5>. lotice 
that according to the following definition QUOTE write protects its 
arguaent. 

<define quote <function £*x] .x» 

<SOPPRESS 

tx}> suppresses evaluation of the fors |x|. Re say 
abbreviate <SOPPRESS 1x|> as !*|x|. For exanple <prog ££x 1]] !•<♦ .x 
5» evaluates to <♦ 1 5>. 

<PBOG 

♦checker* *activa tion-naae* }declaration- 
specification | -body-> where the ♦activation-naae* and ^checker* are 
optional is a naaed prograa block. The |declaration-specification1 is 
of the fora 

£-ordiaary-declarations- 
■'"liBElS" -label-declarations 
-."IMTEHHAIS" -internal-declarations- ] 
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where LABELS and INTEBHALS ace optional. 


Each (internal-declaration) is of the following fora: 

r|fI <F0HCTICH lforsal-paraaetersl -body->] the identifier |f| 
is declared to be an internal function. As snch it has 

special access to the local identifiers of the procedure to 

which it is internal. The identifier ]f| say not have its 

value changed. The following constructs are very efficient 

within the procedure which delares |f| to be internal: 

<]£ I -arguaents-> 

Clf I -argunents-} 
t {| £ | -argunents-!} 

Internal functions provide a rapid aeans of coaaon 
subexpression evaluation. The current fora of internal 
functions is due to Peter Bishop and Dave fieed. 


0% Each (ordinary-declaration) is of the following fora: 

£fattribute-specification] -bindings-] causes the identifers 
in the bindings to be rebound with the appropriate fattribute- 
specif ication | 

where each binding aust be one of the following two foras: 

lidentifierl indicating that the identifier is rebound and 
not assigned a value 


[(identifier] lvalue)] which rebinds the (identifier) with 
an initial (value) 


where Jattribute-specification) aust be one of the 
following: 

(attribute) where each (attribute) aust be one of the 
following: 

(pattern) indicating that the value of the 
identifier aust natch (pattern). A coaaon pattern 

is <0F-TIPE |type-naaej> (abbreviated ! = 1 type- 

naae)) which indicates that the value of the 

identifier aust be of type )type-naae|. 
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-."SPECIAL" indicating that each of the identifiers 
is special aeaning that it can be used as a free 
identifier in other procedures 

[-attributes- ] 


Each |label-declaration| is of the form 

[IfJ (function) ] so that execution <Jf) -arguoents-> mill 
cause control to exit to the point where Iff was declared and 

|function) to he applied to the evaluated -arguments-. 

If control falls through the bctton of the function PROG then it takes 

as its value the value of the last stateaent of the body. If called 
as a procedure a label exits to the activation in which the label was 
bound. 


<prog foo [[x 1 ] 

labels" 

[nonfatal 

<function [z] 

<print (non-fatal .z)> 
<_ :x a> 

<again .foo»] 

[fatal 

<function [z] 

<print (fatal .z)> 
C.foo lose> 

;"exit .foo with 

lose">]] 

;"we have two label procedures 

nonfatal and fatal" 

<prog bar [[y -x] [x 1]] 

<cond 

[<is? .y 1> 

<.nonfatal first-tiae>] 
[-•"else" 

<.fatal second-tiae> ]»> 


evaluates as follows: 


foo is entered 
x is initialized to 1 

the labels fatal and nonfatal are bound 

bar is entered 
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y is initialised to 1 
x is initialized to 1 
C.nonfatal first-time> is invoked 

causing us to 
exit BAB 

(non-fatal first-time) is printed 
x is changed to a 

bar is entered 


y is initialized to a 
x is initialized to 1 
<.fatal second-tiae> is invoked 

causing us to exit FOO 
(fatal second-tine) is printed 
foo is exited with the value lose 


<BLOCKBISD 

♦checker* ♦activation-name* [-declarations-] 

[-*"BINI" Jblock-bindingsJ 

{relative-bindings{ 
jblock-name| 

|block-declarations| 
jagainer| ] 

-body-> 

is exactly like PBOG except that before the -body- is executed a name 

lblock-naae| and a set of block style (e.g. PBOG, FOB, etc.) bindings 
|block-declarations| are established using lrelative-bindings| to look 
up the values of any free identifiers. The resulting binding 
environment is hound to the identifier {block—bindings|. If <AGAIM 
|block-name}> is called, then )againer{ is invoked. The function 
BLOCKBIND is useful for writing interpreters. Be could define BEPEAT 
as follows: 


<define repeat _ 

<functlon p2 

[-•"bind" bl [’name ‘decs -•’•rest" *bd]] 

•"let bl be the bindings before p2 was entered 

and let name be the name of the repeat, 
decs be its declarations, 
and bd be its body" 
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<blockbind pi [[iter .bd]] 

;"let iter be the rest of the body 

to be evaluated" 

[-"bind" b2 
. bl 

• naae 

• decs 
<prog [] 

<_ siter .bd> 

;"if <again .nane> 

is executed, 
then reinitialise 
iter" 

<again *p1»] 

<ccnd 

[<enpty? .iter> 

;"if the body .iter is enpty" 

<_ :iter .ba> 

•"set iter to be the whole body" 
<again .p1>]> 

<eval <1 .iter> .b2> 

<chop iter> 

;"set the body iter to the rest of itself" 
<again .p1»» 


<PBOCBIHD 

♦checker* *activation-nane* [-declarations-] 

[-"BIBt" ]procedure-bindings! 

irelative-bindings] 

|procedure-nane| 
jprocedure-declarations]] 

-body-> is exactly like BLOCKBIHD except that it takes 
procedure style declarations (e.g. FUHCTIOI and ACTOB) instead of PBOG 
style declarations. 


4.5.1.1.3 Escape 


<CALL 

]junction-nane] 

<|activation] -values-> 

If] 

]state-path|> 

leaves the activation [activation] with the given values. The 
expression <[activation] —values—> is an abbreviation for 



CCALL 


<|activation| -values-> 
<FOBCTIOH [X] ,X» 


where X is an arbitrary identifier. The function |f| is applied to 
the values received if the process which calls CIIL is resused. If 
the optional argument |f| is not present and ♦activation-name* is 
defined in another process, then the process which called CALL is 
terminated. 

<AGAIH 

Jjunction-naee| |activation] ]f]> reiterates the 
|activation|. If (activation] is an activation in another process, 
then the process which calls AGAIH will apply the function IfI to the 
values with which it is resumed. If the optional argument |f| is not 
present and |activation] is defined in another process, then the 
process which called AGAIN is terminated. It is illegal to execute 
<AGAIB ]activation|> until all the declarations of |activation| have 
been processed. 


<prog foo [j 

<print 1> 

<again .foo» prints 1 and then prints 

1,prints 1, etc. 


<prog 


bar 
<pi 


[[a <agaio «bar>] [b 3 
rlnt (you can*t gee he 




» causes an error 


<FAIL> generates a simple failure in the match. 


<FAIL 1 message|> causes a failure with a |message| to be 
reported above. A failure with a message can be caught only by the 
function FAI1PCIBT which is explained above. 
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<FAI1 

imessage! 1 place | |f|> generates a failure to |place| 
and then a failure with a |message} from there, the Jplacet aay be 
either a process or an activation. The function ff] is applied to any 
arguments received by being resumed by another process. For exaaple 
down inside a function whose activation is ia| and which has been 
called with a pattern directed invocation executing <fail -•"caller 1 * 

Ial> will signal that none of the other alternative functions should 
be tried. 

4.5. 1.1.4 Repetition 

<REPEAT 

♦checker* ^activation—name* ['declarations-] -body-> 
where the +activation-name* and ♦checker* are optional executes the 
body repeatedly until the body is exited by calling one of the 
functions CALI or AGAIN. Iterative prograaaing in terns of repeats 
has the advantage that all loops are necessarily nested. The repeat 
loop aay be exited with the value x by <.*activation-naae* x> where 
♦activation-nase* is the naae of the repeat loop. Executing <AGAIN 
.*activation-naae*> after —declarations- have been processed transfers 
control to the first eleaeat of -body-. 

♦checker* *activation-i»ane* [-declarations-] 
[[-"INITIAL" -initial-action-] 

[-"STEP" -step-action-] 

[-"TEST" |predicate| -test-action-]] 



<FOR 
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body-> 


where the ♦activation-nane+ and ♦checker^ are optional is defined to 
be an abbreviation for the following: 


<PBOG ♦checker^ +activation-nane + [-declarations-] 

-intial-action- 
<BEPEAT [ ] 

<COBD 

[ ]predicate| 

-test-action- 
<.♦activation-naie+ <>> 

;"exit .+activation-nane+ with <>"]> 

-body- 

-step-action-» 

The FOB loop nay be exited with the vaiue |x| by <•♦activation—nane+ 
|xj> where ♦activaticn-nane+ is the nane of the FOB loop. Executing 
<AGAIM ♦activation-nane+> junps to the point labeled AGAIN in the 
expansion above. Alternatively, we have 


<FOB +checker+ ♦activation-nane+ [-declarations-] 

[[-."IHITIA1" -initial-action-] 

[-."TEST** Jpredicatel -test-action-] 

[-*"LIST" Jiteni -."IF" |condition| ] 

[-."STEP" -step-action-]] 

-body-> 

where the ♦act ivation-naae* and ♦checker^ are optional is like the FOB 
loop previously described except that the value of the for statement 
is the list of all the itens such that the condition is true. It is 
equivalent to the following although it is iapleaented such sore 
efficiently because it only does one cons for each itea in the value. 
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<POB 

♦checker* 

♦activation-naae* 

[-declarations- 

[ COLLECTED ()]] 

• "declare COLLECTED to be initialized to 0" 
[[-."IHITIAL" -initial-action-] 

[-"TEST" 

] predicate| 

-test-action- 

<.♦activation-naae* .COLLECTED> 

S"exit .♦activation-naae* 

with .collected"] 

[-"STEP" 

<C0MD 

[(condition] 

;"add |itea) onto the end of 

COLLECTED if condition 
is net" 



-step-action-]] 

-body-> 


:COLLECTED 
(I.COLLECTED 
litenj) >]> 


In addition to being able to list the eleaents produced ve can append 
or concatenate then. 


<FOB ♦checker* ♦activation-naae* [-declarations-1 

[[-."Oi" (pattern] |value] -final-action-1 ] 

-body-> 

where the *activation-naae* and *checker* are optional executes the 

body of the loop once for each tine that pattern aatches value, <BEST 
value>, <BBST value 2>, etc* until <BEST value n> becoaes eapty. 


<F0B 


♦checker* *activation-naae* 
[•-declarations- [ X | value J ]] 
[[-•"TEST" 

<IS? <EHPTI> .{> 


;"if 1 is eapty then gait” 
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-final-actions- ] 

[-"STEP" 

; n set X to the rest of X" 
<CHOP X> 3 3 

<CCHD 

[<IS? |pattern| .X> 

-body- 

;*if | pattern| Batches X 

execute -body-** ]» 


<FOR ^checker* ♦activation-nane* [-declarations-] 

[[-"IH" |pattern) lvalue) -final-action-]] 

-body-> 

where the +activation-nane + and ♦checker* are optional executes the 

body of the loop once for each tine that pattern Batches <1 |value|>, 
<1 <REST J value)», <1 <REST lvalue] 2», etc. until <RBST lvalue) n> 
becoaes eapty. The '•"IN” variant of a FOR loop was invented for LISP 
II. The above expression is equivalent to: 



<FOR ♦checker ♦ ♦activation-naae* 

[-declarations- [X (value)]] 

[[-."TEST" 

<IS? <BHPTY> .X> 

;"if X is eapty then quit" 
|final-actions)] 

[-."STEP" 

;"set X to the rest of X" 
<CHOP X>]] 

<CCHD 

[<IS? |pattern) <1 *X» 

-body- 

;"if Jpattern) Batches the 

first eleaent of X 
then exncnte -body-"]» 

For exaapie we can define a function which returns the reverse of a 
list as follows: 


<define reverse <function rev [x] 

<for [first [answer () J] 

[[-."in" :first .x] 





4.5 page 116 


[-."final" 

<.rev .answer> 

;"exit .rev with .answer"]] 

<_ 

:answer 

(.first !.answer)»» 

Thus < re verse (a b c)> is (c b a) The following function returns a 
list of the fixed point numbers in its argument: 


<define numbers <function [x] 

<for [[!=fix first]] 

[[-•"in" :first .x] 
[-•"list" .x]]»> 

Thus <numbers (4 a (3 4) 5.0 6 [3])> is (4 6). 


<F0B ^checker* *activation-name* [-declarations-] 

[[-•"INC" Ijl -."BY" |i 1 -."UNTIL" (predicate!]] 
-body-> is eguivalent to 

<F0B *checker* *activation-naoe* [-declarations-] 

[[-"TEST" )predicate|] 1 J 

[-•"STEP" <INC J ]1 JiJ > ] ] 

-body-> 


<F0B +checker* *activation-name* 

[[-."INC" |j| -."BY" |i| 

-body-> is equivalent to 

<F0R *checker* *activation-name* 

[-declarations- 

[S <ABS Ji|>] 

£L (limit)]] 

;"S is the absolute value of the step 

sire which is frozen on entrance 
to the FOB loop" 

;"the limit l is also frozen 

on entrance to the FOB loop" 
[[-."INC" |j| -"BY" .S 


[-declarations-] 
"THBO" (limit|] ] 
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-"OHTIL" 

<IS? CGBEATEB .!> Jj|>]] 

body-> 


<FOH ♦checker^ +activation-naae+ [-declarations-1 

[[ "•"DEC" ] j J -."BY" I i} -"UNTIL" | predicate| ] ] 

-body-> is equivalent to 

<F08 +checker+ ♦activation-naae* [-declarations-] 

[[-•"TEST" Jpredicate| ] 

[-"STEP" <DEC 1j| |i]>]] 

-body-> 


<FOfi ♦checker♦ ♦activation-naae+ [-declarations-] 

[[-"DEC" Jji -"BY" Ii] -"THBO" Uiaitf]] 

-body-> is equivalent to 


I Jl>]] 


CFOB +checker+ +activation-naae+ 

[-declarations- 

[S CABS 1i|>3 

[I |liaitJ ]] 

[[-"DEC" Ijl -"BY" .S -"OHTI1" <IS? <LESS .L> 
-body-> 


1J] 


<FOB ♦checker^ ♦activation-nane^ [-declarations-] 

[[-"THBO" JliaitJ]] 

-body-> is equivalent to: 

<FOB +checker+ ♦activation-naae+ [-declarations- [I 

[[—"IHC" I -"THBO" CABS lliait|>]] 

-body-> 


4.5.1.1-5 Hulti-Process 
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Often it is convenient and note efficent to have aore than one 

HATCHLESS process in existence at one tine. By a process we aean a 
program counter together with a stack. Primitives are needed for the 
following functions: 

1. Creating processes 

2. Causing them to run 

3. Terminating processes 

4. Interrupting processes 

5. Single stepping processes 

<STEP 

lp| In] jcondition|> executes the process |p| for |nl 
elementary steps unless the {condition) is aet in which case it 
returns immediately. The value of the function STEP is the number of 
elementary steps actually executed in the process |p|. The existence 
of the function STEP means that PLAHHEB functions are not necessarily 
HOBOTOHE in the sense of lattice theory. A function f will be said to 
be COMTAIIED in a function g if whenever <f x> converges then <g x> 
converges and furthermore <f x> = <g x>. A function h will be said to 
be HCHOTCNE if whenever x is contained in y then, <f x> is contained 
in <f y>. 

<ISVOKE 

|junction-name| |p| |n| {condition} |f{> executes the 
process |p{ through ]n| complete procedure invocations unless the 
{condition) is aet in which case the value is the number of 
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invocations completed. In this case Jconditionl is a function which 

is applied to the values returned by the invocation. After the 
invocations of jp| are complete control returns to the original 
process where jf| is applied to the values returned by the last 
invocation in )pj. 

<PBOCESS 

|fj |tcp-activationj ]scheduler|> creates a new 
process which begins execution with the Jf|. The expression <PBOCESS> 
returns the name of the process in which it is executed. Processes 
enable us to have multiple lcci of control. We can hold our place in 
the problem solving process in seme of the processes while advancing 
others. If if] is a function then the process expects to be resumed 
with arguments for |f| the first time that it is entered. If ]f] is 
of the form [|g| ]port|] then it will hang on Iport] and apply the the 
function ]g| to the container of values that it extracts from ]port|. 
The |top-activationl specifies how much of an existing process must be 
copied to start off the new process. Copying a process enalbles us to 
preserve its current state and still allow it to continue exectuon. 

The process is scheduled by the process jschedulerl. The value of the 
function PfiOCESS is the name of the created process. The garbage 
collector will terminate a process before it collects the storage for 
the process. If a process returns or fails off its top then it is 
terminated. The function ]f| can handle normal returns and failures 

as it pleases, k process has the following apparant components: 
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-."STATUS" is the status of the process. The status is be one 
of the following: 

-."RESUMEABLE" -."STOPPED* -’"RONABLE" -"RUNNING" 
TERMINATED" 


-."SCHEDULER" is the scheduler of the process 

-."BUNTIME" is the runtime charged to the urocess. 

~»"TIHEBS"is a list of timers fpr the process. The structure 
of a timer is explained above in the section cn interrupts. 


<CALL 

1 junction-name| 

<|p] -send-args-> 

JfunctionJ 
jstate-path|> 

resumes execution of the process )p| with the arguments -send-args- 

from the point that control last left it and suspend execution of the 
calling process. When the process which was suspended by the CALL 
statement is itself later resumed then the arguments received are 
passed as parameters to |function|. If the optional argument 
]function| is not present then the process which called CALL is 
terminated. The expression <JpJ -send-args-> is an abbreviation for 


<CALL 

<1p | -send-args-> 

<FUHCTQN OUT [-."TUPLE" X] <.0UT !.X»>. 

For example «process foo> 2 a> causes <foo 2 a> to be executed in a 
new process. 

An example of the use of more than one process is in computing 
the fringe of an expression. The fringe of an expression is defined 
to be the expression with all interior parentheses removed. For 
example the fringe of (a (b) c) is (a b c) and the fringe of ((a (((b) 
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c)))) is (a b c) . We conjecture that the problem cannot be solved in 

pure LISP without the use of the primitives CONS, LABEL, or P0NCTION. 
We would like to write an efficient program to test whether two s- 
expressions have the same fringe. The problem is analogous to testing 
whether two derivation trees for a context free grammar have generated 
the same string. The function fringe? is not intrinsically 
interesting. Its importance lies in that fact that very similar 
control problems arise when a problem solver is trying to extract 
information from two different areas of investigation at once. We 
would like to be able to hold our place in one of the investigation 
spaces while we resume computation in the other. Multiple processes 
give us the capability which we need. The following symmetric form of 
the definition of fringe? is due to Bob Prankston. 



<define fringe? 

<function cut [x y] 

<prog 

[[EX 

<process tree-walk> 

;"create a process which begins execution 

with the function tree-walk"] 

[py <process €ree-walk>]] 

<.px .x <process» 

<.py .y <process» 

<repeat [temporary] 

<cond 

£<==? <_ :temporary <.px» <.py» 
<cond 

[<is? .temporary (> > 

<• out -.«true">]>] 
[-."else" <.out <»]»»> 

<define tree-walk 

<function £x p] 

<. p> 

;"the first thing to do is to resume 

the main process with no arguments" 
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<tree-walk1 . x ,p> 

;"after doing the complete 

tree walk resume the 
main process with the 
special value ()" 

<• F «»> 

<define tree-walk 1 

<function [x p] 

<cond 

[<empty? .x> 

;"if the structure is 

empty then return 
and try to find another atom"] 
[<is? !«atom .x> 

•"resume the main process with the 

atom we have found" 

<.p .x>] 

[-."else" 

<tree-walk1 <1 ,x» 

;"find the atoms in the 

first element of .x" 
<tree-walkl <rest ,x>> 

;"find the atoms in the rest 

of «x and then 

return to finding atoms on 

the remaining branches" ]>» 


<PCBT> 

creates a structure which contains two compontents: 

EXPOSTSI-PORT is a ring which holds a gueue of containers of 
exports waiting in the port. 

IMPORTERS!-PORT is a ring which holds a gueue of processes 
waitxng to take containers out of the port. 

At any time either or both rings may be empty. Our concept of a port 
is derived from Rudy Krutar, Bob Balzer, and innumerable operating 
systems. The idea is that the port acts as a channel through which 
commerce may be transacted with some processes exporting through it 
and others importing what the others export. The commerce is 





4,5 page 123 

completely containerized, in expression <CA1L <|port| -walues-» will 

place -values- in a container in iDortj. when a process inports froi 
a port it will get one container of values to apply to a function. 
Enpty containers are allowed in which case the function of the 
iaporter will be passed no arguments. 

Another example of the use of aultiple processes occurs where 
there are two line printers and a number of processes which would like 
to get expressions printed, suppose that <POfif-TO-PRIHTEHS> is the 
port to which things to be printed are exported. Furterwore let 
<PRIHT-CHAH*EL1> and <PBIHf-CflAEREL2> be the channels for printer1 and 
printer2 restpectively. 




channej» 





p 


<define printer 

<function [print-channel] 

<repeat [ ] 

;"remove the next element 

from the print-port, 
print it 

on the print channel, 
and repeat" 

<call 

[ 1 
C 

<function [x] 

<print 

• x 

•print- 

<port-to-printers>]»» 

<define setup-printers <function [] 

<<process printer> 

;"create a process for driving 

the first printer and pass it 
its print channel" 

<prin t-channel 1» 

U> 

<call 
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«process printer> 

<print-chaanel2» 

t 3 »> 

After <setup-printers> has been called, then <<port-to- 
printers> |x|> will cause JxJ to be guened and printed in its torn by 
one of the printers. 

Now we would like to show how to do fringe? using ports 
instead of resuwes. 


<define fringe? 

<function out [i y] 

<prog 

[[port-x <port>] 

[port-y <port>] 

[P* 

<process [tree-walk .port-x]> 

;"create a process which begins execution 

hanging on .port-x 

with the function tree-walk"] 

•"at this point an actiwation of .px is waiting 
in .port-x" 

[py <process [tree-walk •port-y]>] 

•"at this point an actiwation of .py is waiting 
in .port-y"] 

<call 

<.port-x .x ,port-x> 

;"export .x .port-x to 

the port .port-x" 

[.port-x ] 

;"wait for a container of walues 

from .port-x"> 

;"at this point an activation of 

.px is waiting 
in .port-x" 

<call <.port-y .y .port-y> £.port-y]> 

;"at this point an activation 

of .py is waiting 
in .port-y" 

<repeat [tenporary] 

<cond 

[<«? 

1<_ :tenporary 
<call 


<•port-x> 
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arguaents 
processes 
and . y" 


[ .port-x ]» 

{"the | allows the two 

of ==? to be coaputed in parallel and thus allows th« 

.px and •py to run in parallel to find the next atoas in .x 


C 


<call 


<•porfc-y> 

;"export 

an eapty container 

to .port-y" 


[.port-y] 

;"wait for a container 

on .poj:t-y"» 


<cond 

[<is? .teaporary () > 
<• cut -«"true">]>J 
"else" < • out <»]»»> 


<define tree-walk 

<function [x p] 

Ccall 

<.p> 

;"export an eapty container of values 

to the port .p" 

£.P] 

{"wait for a container of values 

on the port p"> 

<tree-walk1 «x .p> 

{"after doing the coaplete tree walk 

export () on the port . p" 

<call 

<.p ()> 

{"insert () in the port .p" 

£.P] 

{"wait for a container of values in 

the port .p"»> 

<define tree-walk1 

<function £x pi 

<cond 

[<enpty? . x> 

{"if the structure is 

eapty then return 
and try to find another atoa"] 
[<is? !*atoa .x> 

{"resuae the aain process with the 

atoa we have found" 


<.p *x> 

{"insert *x in the port .p" 


<call 
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£. P] 

;"wait for a contaiaer 

of values 

in the port .p">] 

[-"else" 

<tree-walk 1 <1 ,x» 

; n find the atoms in the first 

eleaent of .x" 

<tree-valk1 <rest .x» 

;"find the atoas in the rest of 

•x and then 

return to finding atoas on 
the remaining branches" ]»> 


<BAIT-CALL 

<1Pt -send-args-> |function|> is exactly like CAtL 
except that it is willing to aait until Jp| becomes resuaeable. 

1<IPI ~args-> might create a new process in which to evaluate 
<1 Pi -args-> in parallel with the normal order evaluation of the 
original process. The first | in the previous sentence is not 
metalinguistic. For example <* |<foo 3 4> <bar 3 5> |<* .x 7> <g 2 
2» initiates evaluation of <foo 3 4> and possibl; in parallel 
evaluates <bar 3 5>. After <bar 3 5> has been evaluated# it initiates 
evaluation of <♦ ,x 7> and possibly in parallel evaluates <g 2 2>. 

When all of the values have been computed# the function * is entered. 

!|<|p| -args-> is exactly like |<|p| -args-> except that if 
one branch becoaes blocked tne other is guaranteed to be able to try 
to continue execution. 


<prog foo [] 

<♦ 

11<stop> 

<•foo 3> 

;**exit .foo with 3"» evaluates to 3 






<FCRK 


4.5 page 127 


<| p| -args->> resumes execut ion of the suspended 
process |pj from the point that control last left it with the 
arguments -args- and in parallel continue execution of the calling 
process. It is an abbreviation for 

CCALI <1pJ -args-> [ ]> 

For example <fork «prccess foo> <bar> a» causes <foo <bar> a> to be 
executed in a new process in parallel with the calling process. The 
value of the function FORK is ip). The list of runnable processes is 
kept in the global value of the identifier RUMti&BlC!>SCR£D01EB. The 
initial scheduler is driven by the following handler for RUNTIHE 
interrupts when a certain amountof runtime has elapsed: 


!£<block (<oblist scheduler!-> <oblist>)> 

<function [] <prog twiddle 

[victem [-•"global" runnable deserving]] 

;"the processes that are still deserving to 

be run are kept in 

the identifier 'deserving'" 

<lccker [] <getc lock schedule-queue> 

;"lock the schedule variables while 

they are being changed" 

<cond 

[<eapty? .deserving> 

<_ :deserving .runnable> 
<again .twiddle>]> 

<_ (:victem !:deserving) .deserving> 
<cond 

[ <is? 

<getc -«"status" . victem> 
-•"runnable "> 

;"if the status is 

runnable then 
change it to running" 

<putc 
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-'"running” ]> ] 


.victen 
[ -*"status" 

l -»"else" 

<again .tviddle>]> 

;"this scheduler is strictly first in 

first out" 

<continue .victem> 

<locker £] <getc lock schedule-gueue> 

<putc 

.victem 

[status -*"runnable"]»»> 


!%<end-block> 

<TEfiflINATE 

-processes-> causes -processes- to be stopped, their 


stacks unwound, their timers and alarms to be unset, and then put into 
a state such that they cannot later be resumed, interrupted, or 
continued. A process is automatically terminated when it returns or 


fails to its top level. 


<STOP 


|p]> stops the process ]p| in such a way that it can 
later be continued or interrupted. 

<CONTINUE 

|p|> causes the process |p] to continue execution from 
where it was stopped. 

<SUSPBND 

Jjunction-name| |function]> suspends execution of the 
process which calls it. It is an abbreviation for 

CCAI.1 |junction-name| £ ] Jfunction}>. 

If the process is later resumed it begins execution by applying 
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JfunctionJ to the arguments received. 

<1NTEBBUPT 

Jjunction-name| |pl <|f| -arguments-> |gj> will 
interrupt the process |pl to evaluate the function |f j applied to - 
arguments- IN THE PBOCISS |pj. If J £| returns normally then its 
values are given as arguments to |g|. Othervise ]gl will be applied 
to the arguments with which it is resumed. The primitive INTEBRDPT 
allovs the definition of functions which are not MONOTONE in the sense 
of lattice theory. 


4.5.1.2 Data Functions 



4.5. 1.2.1 Specialists 


4.5. 1.2. 1.1 Structure Functions 


<STBOCTUBE? 

UP is true only if Jx| is of storage type vector, 
list, stack, ring, or node. 


<define structure? 

<function [x] 

<rule [] <storage 
[<either 
vector 
list 
stack 
ring 
node> 


. x> 
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-."true"] 

-•"else" 

<»» 

<E HPTY ? 

Jx|> is true only if Jx| is an empty structure. 

<define empty? 

<function [x] 

<and? 

<structure? .x> 

<==? <length .x> 0»» 


<flONAD? 

]x|> is true only if ]x| is not decomposable. In 
other words Jx] is net a structure or it is empty. 

<define monad? 

<function [x] 

<or? 

<not? <structure? ,x» 
<empty? ,x»>> 

<CL0SUBE 

|procedure j Jfree-variafcles|> returns the closure of 
the |procedure| with the free variables bound to their values at the 
time when the closure is constructed. The CLOSURE primitive allows 
procedures to to have cvn variables. They enable us to easily 
construct generators such as those of GPS. 


The function twice will take a function f as an argument and return a 
function which applies f to its argument twice. 

<define twice <function Tf] 

<closure <function [x] <.f <• f .x»> f»> 
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«prcg [x 3] 

«closure <function [] .x> x»» evaluates to 


<prog [a [b 1]] 

<_ :a <closure <£unction [ ] ,b> b» 

<_ :b 2> 

<.a» evaluates to 1 

<proa [x 4J 
<prog i 

[y <closure <function [} ,x> x>l 

[x 033 

<.y»> evaluates to 4 

Suppose that we wanted to define a generator )f| to be 
<elenents |x|> such that each tiae that <Jf|> is evaluated it returns 
a new eleaent of Jxl. 


<define eleaents <function £x] 

<closure 

<function [ ] 

<prog [[next <1 .x>j] 

<chop x> 

. next» 

x»> 


How if ve evaluate: 

< pr°, b «>]] 

;"a is printed" 

<print <.f» 

;"b is printed"> 


<BEST 

ixl Jnl +not-found+> returns the result of taking the 
rest of |xl |n| tiaes. if the rest of (x| cannot he taken |s| tines 
then *not~found* is evaluated. 

<rest [a 4 d f3 2> evaluates to (d f] 

<1 <rest <node £1 a] £2 bj>» is b 
<rest <rest [a 4 d f ] 2> -1> is [4 d fl 
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If jnj is positive then, <rest <rest |x| |n|> <- |n(» is an error or 
is identical to |x|. The function BEST with a negative ]n| nay be 
applied only to tuple pointers, vector pointers, and node pointers, 
it say not be applied to list pointers. 

<GET 

(indicator] (object] ♦not-found*> returns the value 
under (indicator) for the (object] if such exists, otherwise it 
returns the value of not—found. Integer indicators have special 
properties so that structures can be nade out of lists, vectors, and 
nodes alaost interchangeably. The expression <]integer] (object) 
♦not-found*> is an abbreviation for <GET (integer) (object| * 00 !- 
found+>« 


<3 (a b c)> evaluates to c 


<-1 <rest [a b c d] 3» is b 

<2 <rest <node £f 00 1] [3 a] [2 b]»> is a 

<2 [a (b c) d ]> evaluates to (b c) . 


<get fco 


<node [foo 1] £4 a]» evaluates to 1 


<GETI-HO-acnitor 

(indicator! (object| +not-found*> is exactly like get 
except that monitors for the location under (object] with arc naae 
(indicator) will not be triggered. 

<WAIT-GET 

(indicator! ]object]> is like GET except that if 
(object] does not yet have anything under (indicator{then the process 
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is suspended until (object! bas soaething POT under (indicator!. 

<AT 

Jil JoJ 4not-found*> returns the location of the value 
under the indicator |i] of the object )o). 

<putloc <at 2 [a 4 ]> 8> evaluates to [a 8] 

<AT |o|> is the locative to the value of the identifer |o] if 
lo) is an atoa and a locative to the rest of |o| if |o| is a list. 

<ABC 


Io| (indicator! ♦not—found+> is the arc froa the 
object 1o| with naae (indicator! if there is one. Otherwise ♦not- 
found+ is evaluated. 

<IIITIAL 

I ♦not-foundO is the initial node arc for the 
object |o| if it has one. Otherwise it returns the value of ♦not- 
found*. 

<BEXT 


1xI ♦nct-foundv> returns the next arc after |x| for 
the object |o|, if there is one. Otherwise it returns the value of 
♦not-founde. 

<EBD? Ioi> is true only if |o| is an end node with no leaves 
leaving it. 

<1AST? 

]xi> is true only if (x| is the last arc of the node. 

<ISX>ICATOB 


|x|> is the indicator for the arc |x| 
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<indicator Cinitial <node [a 3] [4 "r"]>>> is a 

CHEAD 

1 x|> is the object at the head of the arc |x|. 

<head <arc <put 3 [larger 2] [smaller 4]> soaller>> is 

3 

<TAI1 

| x | > is the object at the tail of the arc (x|. 

<tail <arc <node [a 3] [4 "r" ]> a>> is 3 
<LOC AUVE 

Ix|> is the location which holds the object at the end 

of the arc |x]. 

<COPY 

(x |> will completely copy |x|. 

<==? 

]x 1 |y|> is true only if |x| and |y| are identically 

the same object. 

<=? 

|x| |y J> is true only if Ixf and |y| print the saae as 

structures. 

<de£ine =? <function egual [x y] 

<egual1 .x .y .egual»> 

<define egual1 <function equal 1 [x y equal] 

<con d 

[<or? <nonaaic? .x> <aonadic? .y>> 

<cond 

[<==? .x ,y> 

-."true” ] 






ff 


4.5 page 135 


<.equal <»]>] 

£<*=? <type ,x> <type .y>> 

<repeat £] 

<cond 

[<eapty? ,x> 

<cond 

[<eapty? .y> 

<.equal1 -."true">] 
[-'"else*' 

<.equal <>>]>] 

[<eapty? ,y> 

<.equal <»]> 

<prog out [] 

<egual1 

<1 


ifr&J 


[-."else" 


<chop x> 
<chop y>>] 


<. equal <»]>» 



.x 

<c ond 

[<has? 1 ,y> 

<.equal <» ] 
£ -."else" 

<. out> ]» 


• y 

<.equal <>» 

.egual» 


<SIHXLAB? 


1*1 jyl> is true only if |x] and jy| have siailar 
values under their respective positive indicators. Por exanple (3 
"a4" £ I "a ]) is siailar to [3 (!"a !"4) "a"]. 

<define siailar? <function sia £x y] 

<simlar1 .x .y .sia>» 

<define siailar1 <function sial £x v sia] 

<cona 4 4 

[<or? <aonadic? .x> <aonadic? ,y» 

<cond 

[<*? .X .y> 
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C.sia <»]>] 

[-."else" 

<repeat [] 

<ccnd 

[<eapty? .x> 

<c ond 

[<eapty? .y> 

<.sia1 -»"true">] 
[-."else" 

<.sia <»]>] 

[<eapty? .y> 

<.sia <» ]> 

<prog out [] 

<siailari 

<1 


Cchop x> 

<chop y»]»> 


<1 


.sia» 


• x 

<cond 

[<has? 1 .y> 
<.sia <»J 
[-."else" 

<.oat> J» 


•y 

<.sia <»> 



<ISOHOBPHIC? 

|x| |y|> Is true only if Jx1 and ly| are isoaorphic as 


graphs. 


<define isoaorphic? <fanction iso [x y] 

<iso1 .x •y •iso>>> 

<define isol <function [x j iso] 

<cond 

[<*=? <type • x> <type .y» 

<prog out [] 

<sub-iso1 

<initial 
• x 

<,out> 

;"if .x has no arcs then exit 
•Out"> 

•y 

,iso» 
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<prog out [ ] 

<sub-iso1 

<initxal 

<.cut» 

• X 

. iso» 

i"trae n ] 

£ -’"else” 

<.iso1 <»]>>> 

<define sub-iso 1 <functioi* sub-iso-n [x-arc y iso 1 

<repeat [] 

<iso 1 

<tail .x-arc> 

<get <indicator . x-arc> 

•y 

<.iso <» 

; w f .y does not have a arc vith 

<indicator .x-arc> then, 
exit .iso with <>"> 

. iso> 

< 


<next 

.x-arc 

<•sub-iso-n> 

;"exit .sub-iso-n if there are no 

■ore x-arcs M »»> 


<PUTl-PEBSISTENT 


]object] -properties-> puts the properties on the 
{object]• A property of the form [{indicator! Jv|] puts the value 
{v| under t'he {indicator]. A property of the for* £]indicator!] 
deletes the {indicator) frcn the object. Integer indicators have 
special properties so that structures can be aade out of lists, 
vectors, and nodes alaost interchangeably. 

<put <node (a 4] (3.5 c]» (a b] £3.5] (tej 9]> 
evaluates to inode ££a b] ££ej 9J] 

<put (a 4) £1 *c"J> evaluates to ("c" 4) 
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Properties can be put on A HI of the data types of HATCHLESS, for 

example <put 3 [size small ]> puts the Talue sjail under the indicator 
size for the fixed point number 3. The ability to associate any piece 
of data with any othef piece is very useful. For exaaple Gerry 
Sussnan has pointed out that coaaents can be iaplenented in this way. 
The degree to which an expression has been simplified can be recorded. 
For exaaple we aight <put *<♦ 3 4> [simplified canonically ]> to 
indicate that '<+ 3 4> has been simplified canonically. 

<POT!—TENTATIVE 

|object| -properties-> is exactly like POT except that 
the properties of lobject] are restored on backtracking. 

<P0T!-NO—MONITOR 

lobject| -properties-> is exactly like POTI-PERSITENT 
except that the monitors for the locations are not triggered. 

<PUTREST!-PERSISTENT 

]x| |y J |n| +not-found+> changes the REST of the list 
<rest |x| |n1> to be lyi where |y| must be a list. If <rest |x| <♦ 

|n | 1>> is not a list then ♦net-found* is evaluated. 

<putrest (3 a) (4 5) > evaluates to (3 4 5) 

<P0TREST!-TENTATIVE 

|x| Jy| |n| +nct-found*> is exactly like PDTREST 
except that |x| is restored on backtracking. 

<define putrest!-tentative <functicn 

[x -»"optional" 

[I 0 3 
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[n 0] 

[net-found !*Cerror>]3 
<failpoint [[save Crest .x ,n>]] 

Cputrest ,x .y .n .not-found> 
[ -*”optional” ] 

Cputrest .x .save .n>>>> 


CCHOP!-FEBSISTENT 

|x| |nI +not-£ound+> assigns the identifier |x| the 
rest taken J n| times of its current value. The function CHOP was 
invented for a variant of LISP at MITfiB. 



IXCblock (Coblist chop!-> Coblist>)> 

Cdefine chop 

Cfunction 
C ’x 

-•"optional” 

[n 1] 

[*not-fcund *Cerror>]J 

c_ 

:. x 
Crest 

.. x 
. n 

.nct-found»» 

! XCend-block> 


Cprog [[v (1 2)11 

Cchop v>> evaluates to (2) 

CCHOP!-TENTfiTIVE 

|x | |n| ♦not-found+> is like CHOP except that its 
results are not undone on backtracking. 



!%Cblock (Coblist chcp!-> Coblist>)> 

Cdefine chop 

Cfunction 

C 

"•"optional” 

[n 1] 

[*not-fcund *Cerror>]] 

<_ _.x Crest ..x .n . not-found»» 

! %Cend-block> 
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CLBBGTH 

jxj> retarns the length of the value of lx(. 


<length (a b c)> evaluates to 3 

<define length Cfunction In £x] 

<for [[n 0]] 

[[-."in" <?> .x] 

[-'•‘final" <.ln .n> 

;"exit .In with .n"] 

<inc n>3»> 


CIHDEX 

|xl> returns the rest index of |x|. The function 
INDEX is only defined for vectors and nodes. 

Cinder Crest Crest [a e I"e e f g] 2> 3» is 5 


CTCP 


♦not-found+> 


]x] |nf ♦ not-found*> is CHEST Jx| C- *nl CINDEX |xj» 


CBOTTOH 

jx| |xx| «-not-found*> is CHEST |x) <- CtEHGTB |x|> Jn|> 


♦not-found*> 


CUNIQUIZE 

|value|> returns a pointer to the unigue copy of 
lvalue|. The function ONIQ0IZB can be used to save space and tine in 
coaputations. The expression CUNIQUIZE |value|> nay be abbreviated as 
!-*) value|. The function UHIQUIZE is doe to Peter Bishop. 
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<uniguize "e£g"> is ^"efg" 

<uniguize (a !"b £ M e" 3])> is -»{a ! w b -»£-."e" 3]) 

<prog ££x_£ a be]]] 

<uniquize ,x> 

<uniguize <copy ,x>»> is true. 

<UHIQUE1T? 

Jx|> is true only if |x| is a uniguely created copy of 
Ix] i.e. to be <==? |xj CUHIQUIZE !x|». 

<INCBEASING? 

-elenents-> is true only if -eleaents- are arranged in 
increasing order in the the total ordering on unigue expressions. 

SUBSTITUTE 

jx| |patternJ Jz|> substitute the value of |x] for all 
expressions in ]z| that natch ]pattern). 

Substitute a !=aton (1 (x z)) > evaluates to (a (a a)) 


!%<block (<oblist substitute!-> <oblist>)> 

<define substitute <£unction 

£x *p z] 

<subst 

• X 

<eval !*<actor £] .p» 

,z>» 

<de£ine subst <function £x p zl 

<rule £] ,z u J 

£<.p> 

•x] 

£<nonadic> 

.X] 

£ <linear (?) > 

«type .z> 

<subst .x .p <1 «z» 

(subst *x .p <rest .z>}>] 
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[ <?> 

.z ]»> 

!3t<end-block> 

<HEMBEB? 

|pat| |struc|> is the tail of Jstrucl whose first 
element matches lpat| if there is one and otherwise is <>. 

<member? !*atom [3 4.5 {a) b 6 c]> evaluates to [b 6 

c] 

!%<blcck (<cblist member?> <cblist>)> 

<define member? 

<function ['p s] 

<member1 

<eval !*<actor [] .p» 

.s»> 

<define memberl 

<function out [p s] 

<repeat £] 

<cond 

[<is <empty> ,s> 

<. out <»] 

[ <is < ,p> <1 .s» 

<.out ,s>]> 

<chop s»» 

!J<endblock> 


4.5.1.2.1. 1. 1 list 


<11ST!-CONSTBUCTOR 

-values-> constructs a list of -values-, 
equivalent to (-values-). 


It is 
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4.5.1.2.1.1.2 Vector 


Any expression enclosed within «{" and »)» evaluates to a 
list. Any expression enclosed within «•[" and "]" evaluates to a 
vector. 

<1VECTOB 

|n] Jfcn|> creates an inplicit vector of length the 
value of in| with entry i initialized to <lfcn| i>. 


<define ivector <product vector vector [n fl 

[£i <thru 1 .n> ] [<.f ,i>]]» L J 

<ivector 

3 

<function [i] .i» 


evaluates to [ 1 2 3]. 

<1TUPLE 

In| ]£cn|> creates a definite tuple of length the 

value of 1n| with entry i initialized to <|fcn{ i>. A definite tuple 

can only be created as the initial value of an identifier in a 

declaration, as an elenent of a definite tuple, or as an argument to a 

function. 

<1NDEPIBITE 

type [-declarations-] 

[-for-specifications- 

[ -•"EXIT'* | out-naae | ] 

[-»"ADJCIH*' ]expression! ]] 

-body-> 

creates an indefinite tuple by setting up a for loop in which the 
eleaents of the tuple are generated eleaent by element such that 
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condition is net. An indefinite tuple can only be created as the 

initial value of an identifier in a declaration, as an element of a 
definite tuple, or as an argument to a function. An indefininte tuple 
is a good way to pass arguments which are generated incrementally at 
run time. Ho tuples nay be declared in -declarations-. Evaluating 
<.Jout-name|> will cause IHDEFIHITE to return with the tuple 
generated. 


<indefinite 


[[!*fir £i 1]]] 

;"declare i to be a fixed point 

number initialized to 1" 


££-."inc" i -."thru" .n] 

;"increment i thru .n" 

[-."adjoin" .i] 

;"each time through the loop adjoin the value 

of i to the tuple" ] 

;"the body of the loop is empty"> 


evaluates to 


<UHSHABE 


[1 2 3 4] if the identifier n has the value 4 


|x| jtail-of-xj> creates a copy of the value of }x| at 
the top level. The value of |tail-of-xl must be obtainable from the 
value of |x| by repeatedly applying the function BEST. The value of 
the function OHSBABE is equal to its argument but it is not identical. 

<unshare £ 1 x (y 2.0) ]> evaluates to [1 x (y 2.0)] 
<prog ££I=vector £x £a (4)]]]] 

<is? <« <2 .x» <2 <unshare . x»» evaluates 


to true. 


<TECTO81-COISTBOCTOB 
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-values-> constructs a vector of -values-. It is 
equivalent to {-values-]. 

4.5. 1.2.1.1. 3 String 

<STBIHG!-CCKSTBDCTOB 

-values-> constructs a string of the -values-. 

<string 

"Bun" 

n n 

"Dick" 

n h 

"rua" 

evaluates to "Bun Dick run." 

4.5. 1.2. 1. 1. 4 Graph 

<HCDE!-CCHSTBDCTOB 

-properties-> constructs a node with -properties-. 

<SHABE 

]node1 jindicator) Jlocative|> will cause |nodel to 
share the location under Jindicatort with the location Ilocative|. 

The function SHAHE is due to Peter Bishop. 

4.5.1.2.1.1.5 Class 

<CIASSI-COHSTBOCTOB 

-elements-> will construct a class with -eleaeats-. 


4. 5* 1.2. 1.2 Atoa 
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<ATO(i!—CONSTRUCTOR |stringJ> is the atom on the root ofclist 


with print name Istringj. 

<ATOH!-CONSTRUCTOR 

Jstringl Jpath| +not-£ound+> is the atom with the 
print name ]string] in the ]path| of oblists. If the optional 
argument +not-found* is not present and there is not atom on {path] 
with print name jstringl then a new atom is created in <1 |path|>. 


<PNAME 

|atom|> is the print name of Jatom] which is a uninque 


string. 


<pname hellol-dolly!-> is -*"hello" 


4.5.1.2.1.3 Rord and Number Functions 

<BITS 

|s| |p|> defines a field of |s| bits that is |p| bits 
from the right end of the word. 

<SIGNED-BITS 

|s] |p|> defines a signed field of |s| bits that is 
|p| bits from the right end of the word. 

<BITE 

Is| |p I |e|> returns a byte pointer to the byte of )s| 
bits that is |p| bits from the right end of the word pointed to by 
|e|. 


<1NC!-PERSISTENT 
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|var] Jdelta|> increments the value of the identifier 
JvarJ by |delta| and store the result in Jvarf. The body of INC will 

be put in a separate lexical block so that identifier collisions 
cannot occur. 


!%<block (<oblist inc!-> <oblist>)> 

<define inc <function [*x] 

<_ :.x <♦ ..x 1>»> 

! %<end-block> 

<1NC!-TENTATIVI 

lvar| |delta|> is like EEC except that |var| is 
restored in backtracting. 


!*<block (<oblist inc!-> <oblist>)> 
<define inc!-tentative <function [*x] 

<_.x <♦ ..x 1>>» 

!*<end-block> 


<DEC!-fERSISTENT 

Ivar| Jdelta|> decrements the value of the identifier 
Jvarl by |delta| and store the result in Jvar|. 

!%<block (<oblist decl-> <oblist>)> 

<define dec <function £*x] 

<_ : .x <- ..x 1»» 

! *<end-block> 

<DEC!-TENTATIVE 

Ivar| |delta|> is like DEC except that |var| is 
restored in backtracting. 


!%<blcck 
<define 


(<oblist dec!-> <oblist>)> 
dec!-tentative <function £' 
< .x <- •. x 1»» 
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!H<end-block> 

<A SC ESDI MG? 

-elements-> is true only if -eleaents- are in 
ascending order. The function ASCIHDIHG? is due to Gordon Benedict. 


<define ascending? <function out [-•"rest" x] 

<cond 

[<is? <eapty> .x> 

<.out -»"true">] 

[""else" 

<repeat [] 

<cond 

[<is? <eapty> <rest ,x» 
<.out -*"true">] 

[<not? <is? 

<greater <1 .x» 
<2 .x»> 

<.out <»]> 

<chop x»3>» 


<DESCEHDING? 


-elements-> is true only if -elements- are in 
descending order. 

<1DIY1DE 


(dividend| -divisors-> computes the (guotient) and 
|remainder1 of the 1 dividend( divided by the -divisors-. 


[a ! (idivide 7 3H 69] evaluates to [a 2 1 69] 


<call 

<idivide 11 4> 
cfunction [q r ] 

<print .g> 
<print .r>» 

;"prints 2 and then prints 3" 


<♦ 


-numbers-> is the sua of -nnabers-. 





<* 


<ABS 


<♦3 4 -5> is 2 

—numbers-> is the product of —nuabers—. 
<* 5 6> is 30 

Jn|> is the absolute value of |n|. 

<abs -3> is 3 
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<EXPT 

Ibase| (exponent)> is exponentiation. 

<expt 2 3> is 8 

<- 

(subtrahend) -subtractors-> is |subtrahnd| less - 

/'"'S subtracters-. 

<- 3 2> is 1 
<- -5> is 5 
<- 3 9> is -6 

</ 

(dividend) -divisors-> is the floating point nunber 
(dividend) divided by -divisors-. 

</ 4> is .5 
</ 12 3> is 4.0 
</ 3 2> is 1.5 
</ 30 2 5> is 3.0 



<i! AX 
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-values-> is the laxinui of -values-. 
<aax -3 <♦ 4 .1> 4> is 4.1 


<HIU 

-values-> is the ainiaua of -values-. 


4.5. 1.2.1.4 Algebraic 


<!♦ 

-teras-> constructs the sum of the terms. 


<!♦ 

*<* <expt x 2> 3> 

3 

•<♦ 2 x> 

•<* 4 x> 

4 

•<expt x 2» evaluates to 

<♦ 

7 

<* 6 x> 

<* 4 <expt x 2»> 

<!* 

-factors-> constructs the product of the factors. 


<1* 3 <!♦ x 2> <!♦ x -2> x> evaluates to 
<♦ 

<* 3 <expt x 3» 

<* -12 x» 
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4.5. 1.2. 1.5 Locative 


<18 


JlocationJ> returns the contents of (locationI as its 


value. 


<Prog [[x 1]j <in <at x»> evalutates tc 1 


<GENLCC 


lxj> generates a new location (which is not on the 


stack) holding the location of ]x|. 


<in <genloc 3» evaluates to 3 
<PUTLOC!—PBBSISTENT 

(location) Jvalue|> stores the (value( in the 
(location( and return the |value|. it is equivalent to <_ <snash 
]location(> )value|>. 

<prog [x] <putloc <at x> 1» assigns x the value 1 
<PUTLOC!-TENTATIVE 

(location) (value|> is exactly like P0T1CC except that 
(location) is restored on backtracking. 


<define putlocl-tentative 


ion [location value J 


[[save <in .location>]] 
<putloc .location «value> 

[ -^optional" 3 

<putloc .location .save»» 


<VALUE 


(theta| (bindings)> is the value of the identifier 


which is the value of Jtheta(. 
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4.5.1.2.1.6 Stack 


Stacks obey a last in first out storage discipline. 

<STACK 

♦checker♦> returns the nane of a newly created stack 
to store elenents of the appropriate ♦checker^. 

<P0SH 

(stackt -values-> pushs the -values- onto the |stack|. 
The value of POSH is |stack). 

<POP 

|stack| (nuaber) ♦not-found+> pops |nunber| elenents 
off |stack|. and returns then as the values of POF. The elenents 
cone off in the opposite order they vent on. 


(1 I (pop 

<push <stack> a b c d> 
el}) evaluates to (1 deb). 


4.5. 1.2.1.7 King 

Elnents can be inserted and renoved fron either end of a ring. 
CBXHG 

♦checker+> returns the nane of a newly created ring to 
store elenents of the appropriate type. 


<PBOHT 





4.5 page 153 

jring| Jnuaber| ♦not-£ound+> returns the front 
Jnuaber] eleaents of IcingJ. 

<BIAB 

]ring] Jnuaber| ♦not-foaod*> returns the rear |suaber| 
elaents of Jring). 

<INSEBT-FBOHT 

|ring| -values-> inserts -values- into the front of 

Jring |. 

<IHSEBT-BEJIB 

Jringl -values> inserts -values- in the rear of 

JringJ. 

<D EL8TE-FRCNT 

Jringl JnuaberJ +not-found*> deletes Jnuaber) eleaents 
froa the front of Jringl and returns then. 


[a 1 2 b] 
£a 3 2 b]. 


[a !{delete-front <insert-rear <ring> 1 2 3> 21} b] is 
[a ! (delete-rear <insert-rear <ring> 1 2 3> 2!} bj is 


<DELETE-BEAR 


Jring] jnuaber) ♦not-found+> deletes JnuaberJ elements 
froa the rear of |ring| and returns then. 


4.5.1.2.1.8 Character 
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<CHAHACTEB> 

Batches any character. 

<LOIEH> 

Batches any of the twenty six lower case alphabetic characters. 

<OPPEB> 

Batches any of the twnety six upper case alphabetic characters. 

<DIGIT> 

Batches any character which is a digit. 

<AIPHAEETIC> 

Batches any alphabetic character. 

<define alphabetic 

<actor [3 

<either <lower> < upper»» 


4.5. 1.2. 1.8 Iaput-outpnt 

Input-output is transacted through channels. The atonic nanes 
read in are looked up in directories called oblists. 

<CHANNBL 

Idirectioa) ]placet Jplace-dependent|> returns a 
coBBunication channel in the (direction| specified to the |placet 
naaed. The | direction | nay be either -* N REAE" or -« N PBI1T M . 

<CLOSE 

-channels-> terninates transactions on the naaed - 


channels- 




<BESET 
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-channel-> resets (channel]. 

<PRINC 

|S1 jchannels|> prints |s| (which nust be a string or 
charater) literally. It does not put guotes around it or otherwise 
translate (s). 

<PBIH1 

]x] [-channels-] jpath) (print-table} |nacro-tableJ> 
prints the value of |z( on the output channels relative to |path( and 
returns it as the value of the function PBIHT. The various types are 
printed according to the print functions which are defined in Iprint- 
table|. The function PRIST waintains three special identifiers: 
PATHI-PBIHT. TABLE !-PRMT, HAC80S!-PBIIT, and CBA RIELS! -PBIHT. The 
I print-table) nust be a TYPE—fECTOB. The )aacro-table| nust be a 
CHABACTEB-VECTOR which has entries -»"HEVER", -•"BEGIBIHG", or 
-"ALSAIS". 


IKblock (<oblist print !-> <cblist>) > 

<define print 

<function £x -»"optional" 

[-."special" [channels .channels]] 
[-."special" [path .path]] 

[-»"special" [table .table]] 
[-."special" [aacros .aacros]]] 

«getc <type .x> .table> .x»> 

!*<end-block> 


The print function for vectors is: 


<function out [y] 

<cond J 


£<eapty? .y> 

<priac *[]"> 
<*out .y>] 





4.5 page 156 


[-"else" 

<princ !"[ 

;"print the open bracket which 

will be closed by ]"> 

Crepeat [[x .y]] 

<prin1 <1 .x» 

<chop x> 

<cond 

[<eapty? «x> 

<princ 

;"close the [" 
!" ]> 

<.out .y>]> 

<princ !" > 

print a space">]» 


CPHIHT 

|x| |path! |print-table| |channels|> prints a carriage 

return line feed, prints ]x] and then prints a space. The (print- 
table] aust be a TIPE-¥ECTOR. 


<define print 

<fnnction [x -*"optional" 

[-."special" [path .path]] 
[^•"special" [table .table]] 
[-."special" [channels .channels]]] 

<princ " "> 

<prin1 .x> 

<princ " "»> 


<OBLIST> is the root cblist. 

<OBLISf 

{trailer] +not-found»> is the oblist with the 
specified (trailer]. If the optional arguaent +not-found+ is not 
present and there is no oblist with (trailer] then one is created. 

<TRAILER 

|atoa|> is the naae of the oblist on which |atoa] 
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exists. The trailer ef as atoe on the root oblist is <>. 

<0N 

Istringl Jpath|> returns the first oblist in I path] on 
which an atom with prist name jstring| exists if there is one. 
Otherwise it returns <>. 

<LINK 

latoij )path| Jstringl> creates link cn the first 
element of |path) with print nane Istringl. It is an error if there 
is an atom with print nane (string! already on (path). Both Ipatht 
and Istringl are optional. 

<prog [] 

Clink 

top!-middle!-botto* 

(Coblist ne!->) 

**tmb"> 

tmb!-me> evaluates to top!>aiddle!-bottom 


<BLOCK 

|path|> begins a new lexical block where atoms are 
looked up on |path|. The function BLOCK is due to Jerry Sussman. 

<EHD-B10CK> 

closes the current lexical block restoring P1THI-BEID to its previous 
value. 

CB11DCB 

|channel| *not-found*> removes the next character from 
Jchanael|. If there are none, then ♦net-found-*' is evaluated. 

CBEZTCB 

(channel! »not-found*> is the next character in 
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(channel). The channel is not aodified by KEXTCH. If there are none 

then *not-found+ is evaluated. 

<BEAO 

(channel] (path] ♦not-found* (aacrcsl Jsyntax|> 
returns the next expression froa the input (channel) with atoas which 
are not on (path) created in the first eleaent of (path). The aacro 
characters are as defined by functions of one arguaent in (aacros) 
which Bust be of type VECT0B-OE-CHABACTEBS. The arguaent of the 
function is the aacro character which triggered it. The lexical 
syntactic class of each character is defined by (syntax) which also 
aust be a CHARACTEB-VBCTOB. The idea for the read tables is dne to 
John Bhite If there are no aore expressions on the channel, then *not- 
found* is evaluated. The function BEAD aaintains special local 
identifiers CHAHNELl-BEAD, PATH!-BEAD, BCT-FOUHD!—BEAD, H AC BOS!-RE AD, 
and SZBTAX1-BEAD. froa which it obtains the appropriate inforaation. 
The definition of BEAD is: 


!%<block (<oblist read!-> <oblist>)> 


<de£ine read 

<function [-»"optional" 

[-•"special** [channel .channel]] 

[-•"special" [path .path]] 

[-•"special" 

[’not-found 

• <error -*"end-of-file 


reached">]] 


about 


[-•"special" [table .table]] 
[-^"special" [syntax .syntax]]] 
<prog loop [character] 

<_ : character <nextch» 

;"let character be next charaacter 

to be read" 




"ignore"> 
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associated 


<cond 

[<is? <getc .character .syntax> 
<again . loop>]> 

«getc <readch> . table> ,character» 
;"execute the read procedure 

vith the first character"» 


!X<end-block> 

The following ace the aacro characters which are predefined for the 
reader: 


#|type| JobjectI reads {object! then tries to 
convert it to be a I type). 

Por exaaple tcoiplex [3 4] will atteapt to convert [3 4 ] to 
type ccaplex. 

!#FALSE is the unigue object FALSE. 

!#NODE ♦rest-index* [-properties-] where each 
1 property! is of the fora [{indicator] lvalue)] is a node. 

!# PBOPESTIES {objectJ [-properties-] where each 
(property) is of the fora [{indicator! lvalue)] 

is an object with properties. 

IfAHC [{object) (indicator)] is a arc froa {object] 
with naae {indicator). 

1{character) is read as a single character. 

The ! serves as an escape for characters 

which cannot be input directly. 

!!.is.the exclaaation character. 

Thxs is the only way to get in the character !. 


X)fora].reads lfora) evaluate it and use the value as the 
expression read. 

The X aacro is due to Chris Beeve. 


!£l£ora| reads Jfora{evaluate it,and then pretend that 
what was actually read was the null string. 

The IX aacro is due to Chris Beeve. 

The aacro character !X enables us to have side efxects while 
reading. 

Por exaaple: 
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!%<block |path|> causes the reader to read the 

subsequent 

items into |path| until the aatching !*<end-block> is 
encountered. 


$ terainates commands. 

"jstring| w is a character string. 

!"(character| is a single character. 

t Jcharacter 1 reads (character] as though it 
were not a special character. 

In other words t (character| is an ordinary 

alphabetic character to 

the literal reader as though <getc (character! (syntax]> were 
-."alphabetic". 

(-elements-) is a list. 

The read function for !"( is: 


<function [cl 

;"tbe value will be a list" 


<list 


lef t"» ] 


(indefinite [x] 

;"construct a tuple of indefinite size 

made out of the values of x" 
[[-."adjoin" .x] 

[-"exit" out]] 

<call 

<read> 

<function [-"rest" t] 

<cond ... 

[<is? <length .t> 2> 

;"read has returned with 

two values" 

<rule [] <1 ,t> 

[;"first of . t matches (" 
!«) 

;"the first value is 

a right paren" 

<.out>] 

-"else" 

<error 

"mismatched 

[-"else" 

<_ :x <1 .t»]»>}» 
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The read function for !") is: 


<function out [c] 

;"exit with two values so that any 

function which 

calls this one will know 

something is fishy" 

<• out 

;"this should natch (" 

!") 

<»> 


[-elements-] is a vector. 


![-elements-! ] is a homogeneous vector. 

The notation is due to Chris Beeve and Gerry Sussnan. 


<-elenents-> is an element form. 


[-elements-] is a segment form. 

I {-elements-!} is a multiple value segment form. 

II form| is *ALI08-PA11LLBL |fora|. 

!1(form| is fESSEMTIAL-PABALLEL ]fora|. 

latomj!- forces ]atomi to be read into the BOOT oblist. 

It 1 ??* l I , H ai ^ er l* re 2 ds l a * OB l into the oblist vith |trailer|. 
If the following is typed in: 


<prog [] 

foo!-thesis!- 

bar!-preface!-thesis!- 

!S<block (<oblist preface!-thesis!-> 

<o blist thesis! - >) > 

(mumble hello!- foo bar 3 thesis preface) 
! Kend-block» 


then it will evaluate to 

(mumble!-preface!-thesis 
hello 

fool-thesis 

barl-preface!-thesis 

3 

thesis 

preface!-thesis) 
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("expressions- |element) ; 1 comment| -more-expressions-) 
The read function for I"; is: 

<function out [character] <.out !"; <read»> 

(-expressions- jelementl !; Jintent| -more-expressions-) 
The read function for !"!; is: 

<function out [character] <.out !"!; <read»> 


The following prefix macro characters are predefined. 


*(expression| is <QOOT1 )expression|>. 

The * macro is due to John White. 

The read function for the character * is: 

<function [character] ! *<guote <read»> 

I'lform] is <SUPPBESS |form)> which suppresses invocation 
of |form]. 

The read function for !"!* is : 

<function [character] ! *<suppress <read»> 

-•lvalue! is a unique copy of lvalue). 

The read function for !is: 

<function [character] <uniquize <read»> 

I-»| value) is <UHIQOIZE 1 value p. 

The read function for !"!-» is: 


<f unction [character ] ! *<uniquize <read»> 
!»|atom! is <OP-TYPE )atom)>. 

6{form) is <GA1E )form|> 

!t<-elements-> is <TEHP0fiABI <-elements-» 

It (-elements-} is (TEHFOBABY <-elements->} 
!s<-elements-> is <STB1IGBTEH <-elements-» 


Is {-elements-} is {STfiAIGBTEl <-elements->} 
lp<-elements-> is <PEBSISTBRT <-elements-» 
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!p {-elements-) is {PERSISTENT <-eleaents->) 

The macro characters It Is, and Ip are due 
to Peter Bishop. 

.|identifier 1 is <VA1DE (identifier(>. 

I.lidentifier| is {VALUE (identifier 1}. 

,(identifier( is <GLCBAI |identifier^ 

!,(identifier! is {GLOBAL (identifier). 

_1identifier! is <ALTERI-TENTATIVE Jidentifier|>. 

!_(identifier| is (ALTEBI-TENTATIVE (identifier|). 

:(identifier| is <ALTEHI-PERSISTENT 1identifierJ>. 

I: lidentifierj is {ALTERl-PEESISTENT (identifier!}. 

?Jidentifier! is <GIVEH |identifier|>. 

I?(identifier! is {GIVEN (identifier|}. 

4.5.1.2.2 Protection 

CUHPBCTECT 

(z] Iu(> allows access to the object x according to 
the use 1u| which nay be: 

-•"write" for write 
-."execute" for execute 

Restricting the access of a piece of data ensures that it can not be 
used for a purpose which was not intended. For exaaple it can be used 
to insure that checking routines do not aodify the data which they are 
supposed to inspect for errors. 


<PBOTECT 
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|xI Ju}> restricts the uses to which |x| way be put by 

not allowing the use ju| which nay be “•"BEAD", -»"PBT" # or -«"WBITE. 

The use -."POT” protects against putting on non-nuaerical indicators 
whereas -»"BBITE" protects the nuaerical indicators. 


<put 

<2 <protect (a (3 4)) -«"write"» 

£ 1 a ]> causes a write protection error 

<rest <protect {a 2 b) -»"write"» returns (2 b) with 

write protect 


<PBOTECTIOH 

|x|> returns a vector of the protection aodes of 

access for lx|. 

<protection <rest <protect (a 2 b) -»"write"»> is 


[-»"write ] 


4.5.1.2.3 flonitoring 

<HCHITGB 

}1| ffI ]u)> aonitors the location ]1| with the 
function Jf} for the use )u). The use aay be a list of any of the 
following: 

-•"BEAD" for read 
-."EXECUTE" for execute 
-.■BBIIE" for write 

If a process atteapts ho used a aonitored location then <f Hi |ul 
1x1> is evaluated. If a write operation is being atteapted* then x is 
the value which is being stored. If a execute operation is being 
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completed for a function, then x is the tuple of values being 

returned. If an execute operation is being coapleted for an actor, 
then x is the object that was latched. Monitoring is iapleaented in a 
say that is logically eguivalent to creating a arc froa the location 
111 to the list of aonitors for the location |1J under the indicator 
MONITORS. Dave Reed invented the nore efficient aethod that is 
actually used. Monitors are useful for iapleaenting various kinds of 
procedural data. For example they are used to iapleaent break points 
in the language. The following procedure sill aake a list (called 
history-of-x) of all the values that are stored into the special 
identifier x. 

<aonitcr 

<!at x> 

<function £1 u v] 

<_ :history-of-x (.v 1.history-of-x)» 
-»"write"> 

Next se sould like to describe hos aonitors can be used to 
iapleaent an idea due to Peter Landin shich he calls a strean. The 
idea is that the eleaents of a list should be able to be dynaaically 
computed instead of all of then having to be coaputed at once. For 
exaaple in debugging the eleaents of a list night be coaputed 
increaentally as they are needed by being input froa a teletypesriter. 
He could construct such a list |1| as folloss: 

<aonitor 

( 0 ) 

;"the 0 is a duaay which will 

be replaced with the first 
eleaent read" 

.f 
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-*"read"> 


{fere we define f by: 


<define f . 

<function [1 

<aonitor 


u v ] 


<rest 



(<replace <read» 

(replace (0)}) 

. 1 » 


;"aonitor the rest of the list with f" 
-,«read">>> 


Mon <1 Jl|> is the first expression read, <2 11I> is the second, etc. 

<UBHOBITOB 

|1] |pat|> unaonitors the location ill by all 
functions that aatch (pat). 


4.5.1.2.4 Type 

<B1TBACT 

|xj> returns the value )x) retracted to the type in 
which it was defined. The function BETRACT is the identity function 
on objects of primitive type. 

<ST0BAGB 

|x|> returns the prioritise storage allocation type of 
Jx|. The priaitive storage types are LIST, VECTOB, ST BUG, 
HOflOGEBOOS-VECTCfi, STACK, BIBG, ATOM, ACTIVATION, JOBCTICM, LABEL, 
PROCESS, and BODE. 


<TIPE 
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|xj> returns the dynamic type of |xj. 

<DECLABBD 

1x|> returns the declared attributes of |x|. The 
function DECLARED is useful in deciding hov to expand aacros. 

<6 ETC 

(apparent-indicatorl (object] ♦ not-foundO gets the 
|apparent-indicator| component of |object| according to the structure 
definition for <TYPE |object|>. 

<ATC 

Iapparent-indicator| ]object] +not-found*> returns a 
locative to the (apparent-indicator] coaponent of (object] according 
to the structure definition for <TTPE |object]>. 


<POTC!-PERSISTENT 

Iobject| -properties-> puts -properties- on |objectJ 
according to the structure definition for <TTPB (object]>. 

<PDTC!-TEHT1TIVE 

!object! - properties-> is exactly like POTC except 
that the properties of (object| are restored on backtracking. 


4.5.1.2*5 Synchronization 
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<LOCK 

—lock-specifications—> attempts to satisfy the -lock- 
specifications- where each lock-specification oust be cne of the 
following: 

|location| means that Jlocation| is to be locked if it is not 
already locked. 

r-«"BELCCK" {location]] means that {location] is to be relocked 
ewen if it is already locked. 

[-."UHLGCKED" Jlocationi] means that {location] *ost be 
unlocked. 

The process which calls the function LOCK is suspended until all the — 
lock-specifications- are satisfied, suppose that we hawe a data base 
that sometimes is momentarily in an inconsistent state while it is 
being modified. Me would like to set up locks so that arbitrarily 
many processes can be reading the data base at one tine but only one 
process can modify it at a tine, suppose that each data base has a 
RE AD LOCK and a MRITELOCK component in addtion to a COHTBHT component. 


<define read-data-base <function rdb [data-base] 

<prog [current-content ] 

<lock 

[-»" unlocked" 

<atc writelock .data-base>] 
[-•"relock" 

<atc readlock .data-base>]> 
;"in order to read the data base 

the writelock must 
be off and the readlock 
must be relocked" 

< :current— content <getc content .data—base» 

Cunlock <atc readlock .data-base» 

•"is done after the process stops reading" 

<.rdb .current-content> 

;"exit .rdb with .current-content"»> 


4.5 page 169 


<define write-data-base 

<function [data-base new-content] 

<lock <atc writelock .data-base» 

<lock <atc readlock .data-base>> 

;”in order to write the data base the 

writelock 

■ust be locked and 

then readlock aust be locked" 

<putc .data-base [content .new-content]> 
<unlcck 

<atc writelock .data-base> 

<atc readlock .data-base» 

;"is done after the process stops writing"» 

<LCCKEB 


♦checker* *activation-naae* [-lock-specifications-] - 
body-> where the *activation-naae* and ^checker* are optional attempts 
to achieve -lock-specifations- execute the -body- and then unlock any 
locations that were locked by -lock-specifications-. The function 
LOCKEB aakes use of CATCB to insure that the locks are unlocked when 






♦activation-naae* is exited. Be can do the above example as follows 


<defiae read-data-base <function [data-base] 

<lccker [] 

[[ -'"unlocked" 

<atc writelock «data-base>] 
[-."relock" 

<atc readlock .data-base>]] 
<getc content .data-base»» 

<defiae write-data-base 

<function [data-base new-content] 

<locker [] 

£<atc writelock .data-base>] 

<locker [] 

[<atc readlock .data-base>] 

<putc 

•data-base 

[content • new-content ]»»> 


locations-> attempts to lock the locations which are 


<tOCXBD? 
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arguaents. If the locations cannot be locked then the function 

LOCKED? returns <>. 

<0BLOCK 

-locations-> unlocks the locations. 


4.5.1.3 Debugging 

<EBBQB 


Inessage|> will type out the aessage and go into an 


error loop. 


!%<block (<oblist error!-> <oblist>) > 

<define error <function 

[-•"optional" [aessage -»"none"J] 

<print (-•"error-aessage:" .aessage) ,console> 

;"print the aessage on the console channel" 

<repeat [-»"special" loop ] 

[[old-cut .out] 

;"save the old value of out in old-out" 

[-."special" [culprit <fraae 3>]] 

;"the culprit activation is the one three fraaes back" 
-•"labels" 

[-•"special" [out <function [-•"optional" [n 1]] 

;"the label procedure out handles 

exits froa error loops" 

<cond 

[<is? <less t> .n> 

<again .loop>] 

[-•"else" 

<.old-out <- .n 1»]»]]] 

<print <eval <read»»» 

IX<end-block> 


<DEB0G 


(status|. 


|status|> vill set 
The status tay be -»"on" 


the state of the debug state to 
or -."off". 
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<BINDIHGS 

IP I> is the current set of bindings for the process 

IPI. 

<FBABE> is the current activation fraae of the process which 
calls it. 

<FBAHE Jplace|> is the last activation of Jplace] if |place] 
is a process and is |placet if |place| is an activation. 

<FBAHE 

I place] |n|> is the activation frane which is |n| 
frases back frca |place|. 

<PBOCEDOBE 

]fraae|> is the pxocedore of |frase). 

<HABE 

1 procedure]> is the nase of ]procedure! if it has one 
and <> otherwise. 

<PBOCHIHB 

|frane]> is the naae of the procedure for |fraae|. It 
is eguivalent to <BABE <PBOCiBOBE {fraae|». 

<ABGS 

]fraae]> is the tuple of arguaents of ]fraae|. 

4.5. 1.4 Identifier 

<ASSIGVED? 

]var| |b|> is true onlj if the identifier {varl has 
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been assigned a value within the bindings |b|. 

<UNASSIGN 

|varl lb|> nates |var| unassigned within the bindings 

1 b I. 

<BOOHD? 

jvar| |b|> is true only if the identifier Jvar| is 
bound within the bindings JbJ. 


4.5.2 Examples of the Use of Functions 

The function factorial is defined below in order to illustrate 
the syntax of functions that produce values. On entrance to REPEAT, 
temp is immediately bound to 1. 


<define factorial 

<function factorial [n] <repeat [[temp 1]] 

<cond 


[<is? <less 1> ,n> 

<.factorial .temp> 

;"exit .factorial with .te»P"]> 
<_ :temp <* .n ,temp» 

<dec n»» 


Using a foe statement, we can define factorial as follows: 


<define factorial 

<functicn fact [n] 

<f or 


[[temp 1]] 

[[-."dec" n -."thru" 1] 
[-."final" 

<.fact .te«p> 
;exit .fact with 
< :temp <♦ .n ,te»p>>»> 


.temp"]] 
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Thus the value of <faciorial 3> is 6; and the value of <factorial <♦ 


2 2» is 24 
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4.6 Actors in Patterns 


Examples of actors are VEL for disjunction, MCH for negation, 
ALL for conjunction, ahd STAR for Kleene star in general regular 
expressions. He use the characters { and } to delinit actor calls 
that are to natch as segaents. 


<prog [a b c] 

•"we are inside a progran. we have declared the 

identifiers a b and c. 

In the assignnent statenent below the pattern 
(k {all _a _b) _c) is matched against 
(k x y z) . 

The pattern (all _a _b} matches am expression 
only if both _a and ~b match the expression.** 
<is? (k {all _a _b) _c) {k x“y z)» 
a gets the value (x y) 

b gets the value (x y) 

c gets the value z 

<prog [i c] . 

<is? (!_x (either (th) (t»)j !_c) (a o tw th) » 

x gets the value (a o) 

c gets the value (th) 

<prog £x] 

<is? {(star aj _x) (a a a a)» 
x gets the value a 

The argument of the actor HHEI is a list of clauses. If the object 
that the actor HHEN is trying to match has the property that it 
matches the first element of one of the clauses then it must match the 
rest of the elements in that clause. 


<ptog [[!*fix x 3] 

<is? <when [<?> _x]> 3» 

x gets the value 3 since 3 is a fixed point number. 
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In the expression below <all _a _b> Batches 3 only if both _a 
and _b Batch 3. Thus both a and b are set to 3. 

<prog [a b] 

<is? <all _a _b> 3» 

1 nuaber of actors are defined below. 

k palindroae is defined to be a list that reads the sane 
backwards and forwards. Thus (a (b) (b) a) , (), and ((a b) (a b) ) are 

palindroaes. Bore foraally in BATCHLESS, a palindroae can defined as 
an actor of no arguaents: 


<define palindroae 

<actor £] 

;"palindroae is a actor of no arguaents" 

<either 

<eapty> 

;"a palindroae is either eapty or" 
declaration [ x ] 

;"declare a new local x" 

<list _x (palindroae) ,x> 

;"let x be the first eleaent of the 

linear streetare. 

Also x east 
be the last eleaent 
with a palindroae 
in between"»» 


For exaaple 

<is? <palindroae> (a 1 1 a)> is true. 

The fora ACTOB is like the function of LISP except that it is osed in 
actors instead of in functions. The above definition reads: a 
palindroae is a list or vector such that it is eapty or it is a list 
or vector which begins and ends with x with a palindroae in between. 
The actor SABE causes the identifier x to be rebound every tine that 
palindroae is called. The actor BEYBBSE is defined to be such that 





FORMAT OF ACTOR ACTIVATIONS 

IN SNAPSHOTS 


IDENTIFIER-BINDINGS 



NEW ] 

j IDENTIFIER | 

| BINDINGS I 

I_I 

NOTE : THE IDENTIFIER-BINDINGS 

AND RETURN-CONTROL POINTERS 
OF AN ACTIVATION ARE USUALLY 
THE SAME AND THUS ARE 
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BACK 
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<is? <reverse .x> .y> is trueonly iftievalue of x is the reverse of 
the value of y. The definition of reverse is 


define reverse 

<actor [ x] 

<when 

£ <sonadic> 

;"if the object being Batched is aonadic 

then it must be egual to x" 

-*] 

[declaration [first rest] 

{"otherwise let first 

be the first eleaent 
of the Batching object 
and rest 

be the segaent of the rest of 
the eleaents of the 
Batching object." 

Clinear .first !_rest> 

; N when <linear (reverse .rest) .first> 

Batches .x we are done" 

<be <is? 

<linear 

(reverse .rest) 

.first> 

. x»> ]»> 


For exaaple 

<is? <reverse (x y z) > (r y x) > is true 

Hany of the ideas for the actors cone froa Post productions, 
B1F, general regular expressions, EL11S1 (Slagle's algebraic pattern 
Batcher), SHOBCI, COIVEBT, and 1ISP. Be give exaaples of the use of 
these actors afterward. 


4.6.1 Definitions of ictors 
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4.6.1.1 Control Actors 


4.6.1.1.1 Conditional Actors 

<== 


Ix|> Batches an object only if the value of |x| is 
identical to the object. 

<NON 

|pattern|> matches an object only if |pattern} does 
not aatch the object, thus <non c> Batches a, but <non a> does not 
natch a. 

<VEL 


-patterns-> Batches an object only if sene pattern in 
turn Batches the object. If a simple failure backs up to the actor 
VEL, then the next alternative pattern in turn is tried. If all the 
alternatives are exhausted, then VEX. itself propagates a simple 
failure backward. Por example 


<prog [[a 3]] 

<_ (<vel 4 _a> <♦ .a 1>) (4 5)» 

a is initialized to 3 
4 is Batched with 4 
<♦ 3 1> fails to Batch 5. 

_a is Batched against 4 giving a the value 4 
<♦ 4 1> Batches 5 

<prog [a b] 

{<vel ?a ?b> ?a) 

(3 4)» 

a gets the value 3 

3 does not aatch 4 so a siaple failure is generated 
a gets the value iunassigned 
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b gets the value 3 
a gets the value 4 


The following exaaple shows how VEX. is different froa EITHEH: 

<prog £a b] 

<is? 

( 

<either ?a ?b> 

?a) 

(3 4)» 

evaluates to <> which is false since EITHEB does not try Batching ?b 
with 3 because ?a successfully latched 3. 


CALL 

-patterns- > Batches an object only if each pattern in 
turn Batches tie object. 

<IS-ACTOB 

lpattern|> will Batch an object only if the object 
Batches the value of {patter^). 

<BE 

|predicate|> Batches an object only if the {predicate] 
is not false. In other words the actor BE ignores the object that it 
is supposed to aatch and considers only the value of predicate. 

<be <is? 3 3» Batches anything 

<be <» does not natch anything since <> is false. 

<HATCHIBG 

{{object) )tail| |loc{] {predicatep is exactly like 
the actor BE except that the identifier {object| is bound to the 
object being Batched, )tail| is bound to its tail if it has one, and 
)loc| is bound to a locative to |object| if there is one. 
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<WHEN 

♦checker* -clauses-> where each clause is of the fora 
[lpattern| -aore-patterns-] or of the fora #DJCLABE [[-declarations-] 
|patternl -aore-patterns-] Batches an object if the first eleaent of 
soae clause in turn Batches the object and then the rest of the 
eleaents in that clause aatch the object. 


<prog [x y] 

<is? 

<when [<nuaber> _x] [_y]> 
foo>> 

;"y gets the value foo since foo is net a number" 

<prog [[!=fix [y 1] x]] 

<xs? 

<when 

[<be <is? x <♦ .y 1»> 

<♦ .x 2>]>~ 

4» 

;"x gets the value 4* 


4.6. 1.1.2 Block Structuring 


<DECLAflATION 

[-declarations-] -patterns-> matches an object only if 
each pattern in turn Batches the object after -declarations- are 
bound. 


<_ 4declaratioa[[x] _x] 4> 
x gets the value 4 ~ 

<ACTXVE 

<|procedurei -args-> |place|> Batches the pattern 
jprocedure) against all the currently active procedures within 
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1 place]. If the natch succeeds then -args- are latched against the 

procedures arguments. The |place| nay either be a process or of the 
form [Jnamell ]name2]] where ]name1| and |naae2| are the 

names of blocks for a process. 


4.6. 1.2 Data Actors 

4.6. 1.2. 1 Specialists 

4.6. 1.2. 1.1 Structure Actors 

Any expression delimited by w {** and matches a list. Any 

expression delimited by "[" and " ]" matches a vector or a tuple. 

<?> matches anything. 

<? 

Jn|> matches an object only if the object has length 
the value of |n|. For example the following are true: 

<is? <?> (b a c)> is true. 

<is? ({?}) ()> is true. 

<is? (a {?}) (a) > is true. 

<is? (a {?}) (a b) > is true. 

Something of the form * 1x| matches only those objects which 
are egual to ix|. For example *.u matches .a and *a matches a. 

<? 

In| |pattern|> will match anything of length |n| which 


in turn matches |pattern| 
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<prog [four-characters ] 

<is? 

[<? 3> <? 4 :£our-eleaents> <?>] 

£ a h c d e f g h i ]> 

;"four-elenents has the value £d e f g]"> 

<STAB 

-patterns-> Batches an object only if the object 
consists of a seguence (including the null sequence) of elements that 
Batch patterns. For exanple <star 3> Batches (3 3 3) and (a (star b 
c) e) Batches (a b c b c e). 

<DAGGER 

-patterns-> Batches an object only if the object 
consists of at least one seguence of elenents that Batch patterns. 

For exaBple <dagger 3> Batches (3) and (3 3) but does not Batch ()• 

<OPTIOHS 

-patterns-> Batches a seguence of elenents which natch 
a subsequence of the patterns fron left to right. For exanple 
Coptions a !=fix !=atoa> Batches (a 3). 

<HAS 

-properties-> Batches any object with the appropriate 
properties where each property is of one of the following fores: 

[(indicator| ] fails if there is an object under 

I indicator (. 

oresent [I indicator|] reaoves the value under the (indicator! if it is 
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The actor HAS allows MATCHLESS to do pattern Batching cn arbitrary 

graph structures. The exaaple of the syntax of LISP given below shows 
how we can write graBaars over graphs. The idea of developing pattern 
structures over graphs has been generalized and extended in PLAHHEB. 

< 

<has ["x" 3] £4] [c <replace 5>]> 

<node [c [4]] £4 5] £ *x" 3 ]» 


inode £["x" 3] [c 5]] 

< SELECT 

ipat] (other|> Batches any structue such that one of 
the elements of the structure Batches (pat] and the renainder of the 
structure Batches (other(•• 

<prog £r] 

<select 3 _r> <class 4 3 5> 

;"r gets the value <class 4 5>"> 


<0F 


(pat) (collect] (other) > Batches any structure such 
that the list of all the elements of the structure that patch (pat| 
Batches the pattern (collecti and the rest Batch the pattern (other|. 
For exaaple 


<prog £ integers others] 

<_ 

~ <of !=fix integers others> 

£a 3 b 5 9>> 

integers gets the value (3 5 9) 
others gets the value (a b) 


<STB0CT0BE> 
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Batches any list, vector, or node. 

CEHPTY> 


Batches any eapty structure. 

CMCBAD> 


Batches any object which cannot be deconposed. 

CLINE A a 


-patterns-> Batches any list, vector, or tuple whose 
eleaents natch the patterns in order. For exaaple Clinear 3 4> 
Batches (3 4) and it also Batches £3 4]. 

CHEMIST 


|x|> Batches any object such that the object is as 

eleaent of 1x|. 

CCOSTAIMS 


|patl> Batches any structure which contains an object 
that Batches ipatj. 


IXCblock (Coblist contains!-> <oblist>)> 

Cdefine contains 

Cactor 

[•y] 

Ccontainer 

<eval !*<actor (} .y»>» 

Cdefine container Cactor fxl 

Cwhen 

[C.X> 

;"if the actor x Batches 

the Batching object 
then we are done"] 

[Cacnadic> 

;"if the Batching object is 

Bonadic then fail" 

Cfail>j 

[Clinear Ccontainer .x> .{?}> 
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;"if the ficst element in the 

matching object contains x 
then ve ace done"] 

[<?> 

;"else the rest of the matching object 

must contain x" 

Clioear <?> (container . xj>]>» 


lf<end-block> 


<BEP1AC1 


|x|> matches an; object. As a side effect the object 
which is matched is replaced with the value of ]x|. 



<prog [y] 

<is? 

<all 

_y 

(<replace a> (replace (b)})> 
(c d e)>> 

y gets the value (a b) 

lie can define an actor rev which changes any list which it matches to 
the reverse of that list. 


<define rev <actor [] 

<either 

<eapty> 

Clinear <?» 

<declaration (first last] 

<linear : first {?} :last> 
<linear 

<replace .last> 

(rev) 

<replace ,first»»» 


How if evaluate 



:c (e f g)> 
<rev> .c> 


then c mysteriously has the value (g f e) because 
destroys the initial list to make the reverse. 

<PBECED£S 


the actor rev 
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Ix1> will Batch anj expression which precedes |x| in 

the total ordering on expressions. Pot example <precedes «c"> will 
natch "a" since ’•a" prcedes "c w . 


<FOLLOBS 


]x|> will natch anj expression which follows |x| in 


the total ordering on expressions. 


4.6.1.2.1. 1.1 list 


<LIST!-DECOMPOSES 


-patterns-> Batches lists whose eleaents natch - 


patterns-. It is equivalent to (-patterns-). 


4.5.1.2.1.1.2 Vector 


<VECTGBI-DECCHPOSEB 


-patterns-> Batches vectors whose eleaents natch - 


patterns-, it is equivalent to [-patterns-] 


4.6.1.2.1.1.3 String 

<STBI1G!-DECOMPOSES 


-patterns-> Batches strings whose substrings Batch - 


patterns-. 


<prog [first rest] 

<_ 

<string !_first 


! 
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"see the boy"» 
first gets the value "see" 
rest gets the value "the boy" 

<P ro 9 £ r <°*^ s triag j_xoot «s"> "eats"» 
root gets the value "cat" 


4.6. 1.2. 1.1. 4 Graph 

<RODE!-BECOPCSIB 

-properties-> is equivalent to <AI1 !=HO0B <HAS - 


proper ties-». 


4.6.1.2.1.2 Aten 


<ATOH!-DECOHPOSEB 

|s| |o|> will Batch an aton whose print nane is the 
string |s| and which is on the oblist naaed JoJ. 


4.6.1,2.1.3 lord and Huabec Actors 


<BUHBBB > Batches an object only if the object is a nnaber. 
For exaaple <nuaber> Batches 3. 

<LESS 

|n|> Batches any nuaber less than the valae of |n|. 

<LESS= 


|n|> Batches any nuaber less than or egual to the 

value of ]n|• 

<GBEATIB 
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|a|> matches any number greater than the value of jn|. 
<G8EATIB= 

Jn|> matches any number greater than or equal to the 

value of |n|. 

<FIELDS 

-specifications-> matches any fixed point number which 
meet each specification of a field in turn. A fixed point number x 
meets a specification cf the fora [JbitsJ (pattern|] only if the 
number which is the byte of x defined by |bits| matches )pattern 1. 

The expression <bits (s{ Jp|> defines a byte ]s| bits wide which is 
|p| bits from the right end of the word. 

<fields [<bits 3 0> 4] [<bits 1 35> 1 ]> matches a 
fixed point number whose lower 3 bits are 4 and whose sign bit is on. 

4.6.1.2.1.4 Algebraic Actors 

The motivation for providing algebraic actors is to enable 
pattern directed algebraic simplification to be easily accomplished. 
Often it is not clear which simplified form is most useful. Using the 
hierarchical backtrack control structure of FLASHES one form can be 
tried as a hypothesis and then in the light of this experience perhaps 
another more suitable one. 

<! ♦ 

-patterns- |rest-of-sumnands|> matches a sum such that 
each pattern matches a summand and the rest of the summands match the 




4.6 page 188 


pattern Jrest-of-suaaandsJ. 


<is? 

<!+ a b <?» 

*<♦ c b a» is true. 


<prog 


[y * i 3 

<is? 


<1♦ <all <non c> jz> 
*<+ c b a»> 


z gets the value b 
y gets the value c 
x gets the value a 


_y _*> 


<prog [y 


<y 7 


<!+ _y b _x> 

• <♦ 1 c b“a>» 


y gets the value 1 
x gets the value <+ d c> 


<SUH-OF 

lpat| | teras-that-Batch-pat J lrest-of-suanandsl> 
aatches any sub such that the sub of the suaaands that natch |pat| in 
turn natch the pattern Jterns-that-natch-patj and the rest of the 
suaaands natch the pattern |rest-of-suaaandsl* 


<prog [y] 

<is? 

<sua—of <1* x <?» _y <?» 
*<♦ <* 3 x> <* y a>>» 
y gets the value <♦ <* 3 x» 


<!* 

-patterns- |rest-of-factors|> Batches a product of 
factors such that each pattern aatches a factor in the product and the 
rest of the factors Batch the pattern |rest-of-factors|. 

<is? <!* 5 b c> •<* c b 5» is true. 
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<prog [x yj 

<is? 

<!* <all <nunber> x> y <?» 
'<* <♦ 2 a> 3 a»>” 
z gets the value 3 
y gets the value <♦ 2 a> 

<prog £x] 

<is? <!* 3 jt 1> 0» 

x gets the value 0 


<PBODUCS-OF 


lpat| |factors-that-natch-pat| |rest-of-factors|> 
Batches any product of factors such that the product of tbs factors 
that Batch pat in turn natch |factors-that-aatch-pat| and the rest of 
the factors natch the pattern |rest-of-factors)• 


<prog £x y] 

<is? 

<product-o£ <non <nuaber» x y> 
!•<* a 3 b 5.0»> 
x gets the value <* a b> 
y gets the value <♦ 3 5.0> 


<POBBB 


|base| 1 exponent|> Batches an exponential. 


<prog [x y] 

<is? <po«er _x _y> *<expt y 2>» 
x gets the value y ~ 

y gets the value 2 

<prog £x y] 

<is? <pover jt 0» 
x gets the value 0 


<EXTBACT 

Jpat| |teras-vith-pat-extracted| |rest-of-terns|> 
Batches a sun of terns such that the sua of the terns which contain a 
factor which Batches |pat| Batches |terns-with-pat-extracted| and the 
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sum of the rest of the terms matches the pattern Jrest-of-terms|. The 
actor BXTBACT is due to W. Bledsoe. 


<is? 

<eztract x <!♦ 3 a 0> y> 

!*<+ !*<* a x> j I *<* x 3»> is true 

Joel noses invented the example of defining a quadratic in x 
using patterns. 


<define guadratic 
<actor 

[x a b c] 

<extract 

<pover .x 2> 

<all <non 0> <non <contains . x» <.a»> 
<extract 

.x 

<all <non <contains *x» <.b»> 
<all <non <contains .x» <.c»» 

Thus if 

<prog ££"special" al bl cl]] 

<is? 

<quadratic 

y 

<actor [] _a1> 

<actor £ ] _b1> 

<actos £ ] “d» 

<!♦ 

a 

<!* 3 J> 

<!* z *<expt y 2> 4> 

<1* c y»» 

then 

al gets the value <* z 4> 
bl gets the value <♦ 3 c> 
cl gets the value a 


4. 6- ]. 2* 1.5 locative 
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4.6. 1.2.2 Type 

<OF-TYPE 

]atoa]> Batches an object JoJ only if <==? CTYPE ]o]> 
]atoa]> i.e. only if |o| is of the type |atoB|. The expression <0F- 
TYPE |atoB|> nay be abbreviated as I^Jatoat. 

<AS 

(pat) ]inj|> Batches an object x only if x is of the 
type of the range of the injection ]inj] and <BETBACT x> Batches the 
pattern |pat|. 

4.6. 1.3 Identifier 

<GIVEH 

1theta] -bindings-> acts like <fALOE ]theta] - 
bindings-> if the identifier Jtheta] has a value. Otherwise <GIVEH 
|theta| -bindings-> Batches an object x only if the identifier |theta] 
Batches x. 

?|theta) is an abbreviation for <GIVEH |theta]> 

!?]theta| is an abbreviation for {GIVES ]theta]} 

<ALTEBJ—PBHSISTEHT 

(theta] -bindings-> Batches any expression x which 
Batches the identifier ]theta] and gives )theta I the value x. 

:(theta] is an abbreviation for <A1TSB Jtheta|> 
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!:|thetai is an abbreviation for {ALTER Jtheta]} 
<ALTBB{-TENTATIVE 


|theta 1 -bindings-> Batches any expression x which can 
natch the identifier ]theta|. The identifier ]theta) is given the 
value x. However, if a failure backtracks to ALTEB{-TENTATIVE, then 
Jtheta| is restored to its previous value. 

thetaj is an abbreviation for <ALTEBI-TENTATIVE 

(theta |> 


!_|theta| is an abbreviation for {ALTEB{-TENTATIVE 


I theta 1} 


4.6.2 Exanples of the Ose of Actors 

The rest of our examples of the use of actors cone froa giving 
a rigorous definition of the syntax of LISP in MATCHLESS. Those 
readers who. are not interested in the details of the syntax of LISP 
should not read section 4.6.2 The following grammar accounts for 
essentially all the context dependent features of the LISP syntax. It 
specifies that a function call aust have the right nuaber of 
arguments. An explicit go aust have a tag to which it can go. The 
syntax specifies that soae identifiers are free and others are bound. 

<define top-function <actor [] 

<declaration 

{["special" [tags () 3 [boundvars ()]]] 

(function <varlist> <fora>)»> 
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Thus foe example <top-function> Batches (function {) ()). The actor 

top-fnnction introduces the pattern identifiers tags and boundvars and 
binds then to - - which is the null segment. 

<define varlist <actor [3 
<star 

<declaration 

[ [! »at ob curwar]] 

_curvar 

<be <is? _boundvars (.curvar ! .boundvars)»»» 

The actor varlist checks each identifier in turn to sake sure that it 
is an aton and then puts the identifier in boundavars. 


<define 

fora <actor [ ] 

<vhen 

[<nonadic> 

<either <constant> <var»] 

£ 

(! =aton (?}) 

<vhen 

£ (Prog (?)) 

<progforn>] 

[ (cond (?)) 

<condfora>] 

£ (setg (?}) 

(<?> <var> <fora>)] 

C (go {?}) 

<gofora>) 

[ «has [subr <?>)> (?)) 

(<?> (star <fora>}) ) 
[ (<has [expr <?>)> (?)) 
<exprfora>] 

[ (<has [fexpr <?>]> (?}) 
<?>] 

£ (<has £fsubr <?>)> {?)) 
<?>] 

£ (<has £ Isubr <?>)> {?)) 

(<?> (star sfora>)) ] 
£ (<has (lexpr <?>]> (?}) 
(<?> (star <fora>) ) ) 

£<?> 

<aatcning 


[expr optional"] 
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<print (.ezpr undefined)»)>] 

[{(function {?}) (?)) 

<f unction-'f unction> ] 

[<?> 

(<form> (star <fora>)) ]»> 

The above definition says that if a fora is a aonad then it aust be a 
constant or an identifier; if its first eleaent is an atcn then if it 
begins with the atoa prog, then it aust be a progfora etc.; if it 
begins with "((function .„) .. )" then it aust be a function-function 
otherwise it aust be a fora followed by a foralist. 


<define constant <actor [ ] <either t () <nuaber»» 


The only constants are t, (), and nuabers. 


<define war <actor !=atoa [] 

<elt her 

<eleaent .boundvars> 

<unbound»» 

An identifier is either in boundvars or it is unbound. 


<define condfora <actor [] (cond (dagger ((star <fora>})))» 

progfora <actor [ ] 

<declaration 


[ 

["special" 

[tags .tags] 

[localtags () ] 

[boundvars .boundvars]]] 

(prog 

<varlist> 


(all 

<collect-tags> 

<be <is? .tags (!• local tags l.tags)» 
<star <either !=atoa <fora»>})>» 


• • 
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On entrance to progfora tags and boundvars are rebound to their 

previous values. The prog identifiers of the prog are put in 
boundvars, the tags in the prog are put in tags by collect-tags, and 
the body of the prog is checked to see if it is well foraed. 


<define 

collect-tags <actor [ ] 

<star 

<either 

declaration [ 

[!=atoa curtag] 

["special” localtagsj] 
curtag 
<be <is? 

_localtags 

(.curtag !.localtags) » 

<vhen (<eleaent .localtags> 

<error "aultiple defined tag w >] 

<?>»»» 

define 

exprform <actor [ ] 
declaration 

[args functicnvar] 

( 

<has (expr (function _functionvar (?}) 

(all <star <fora» _args|) 

<be <==? <length . functionvar> <length ,args»»» 


An exprfora is a call to an expr with the correct nuaber of arguaents. 

Hote that iaaediately inside the actor exprfora the identifierss args 
and functionvar are rebound but reaain unassigned. 


<define gofora <actcr [ J 
(go 

<vben 

[!*atoa 

dither 


<eleaent .tags> 

<print (.curtag undefined tag)»] 


[<fora> J>)» 
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& gofora is either an explicit call to go to a tag which aust be in 
.tags or a computed go. 


function-function <actor [] 
declaration 

[args functionvarj 

( 

declaration 

^ ["special" [boundvars (.boundvars)]]1 
(function 

<all <varlist> _functionvar> 

<fora>)> 

(all <star <fora» ..args}) 

<be <==? <length .functicnvar ,args»»» 

In a function-function the bound identifiers of the function aust be 

added to boundvars and the function-function aust have the proper 

nuaber of arguaents. 

The above syntax could easily be extended in several 
directions. For example we could easily aodify it so that it would 
accept type declarations and do type checking. The syntax of 
HATCHLESS could easily be defined in HATCHLESS. 
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4.7 HUBBLE 


Section 4.7 is logically completely separate from the rest of 
this report. It is not necessary to read this section to understand 
the rest of the document. 

Be are interested in exploring good mays to implement systems 
like PLAHHEH on machines. One way is to embed the system in a 
language like LISP or PL-1. The problem with embedding is that the 
host language has its cwn conventions for calling segnences and saving 
temporaries. The conventions might not be compatible with the system 
which is being implemented. Another approach is to try to develop a 
formalism which is sufficiently flexible so that it can adapt to the 
higher level system conventions but still is efficient enough so that 
it is feasible to use as an implementation language. The applicative 
sublanguage of HATCHLESS seems to be at approximately the right level 
with the restriction that the data are no longer have types associated 
with them at run time. Thus all the type information must be able to 
be processed at compile time. The general type definition fornalisn 
remains although the definitions must be processed at compile time. 
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4.8 The Editor 

<EDIT 

1zt> enables editing the structure 1 x j. The editor 
maintains a special identifier COBSOBJ-EDIT which represents the 
position of the editor within the structure. & command may be 
abbreviated by the first letter in its name. The editor makes use of 
the tentative versions of the structure modifying commands so that the 
results of a series of edits can be undone by backtracking. Gregory 
Phister made suggestions and implemented an editor. 

<BEHEATH |cursorJ> is the expression beneath )cursor| or <> if 
there is none. 

<COHTAIKS |cursor|> is the structure which contains (cursor 1 
or is <> if there is none. 

<ABC lcursor|> is the indicator under which <BEHBiTn |cursor!'* 
is found under <COHTAIMS Jcursor|> or is <> if <CGBTAIBS (cursor)> is 
<>. That is if <COBTAIIS (cursor|> is not <> then: 

<get 

<contains (cursor]> 

<arc (cursor)>> is <beneath (cursorI> 

<GO | n 1 J cursor J> moves (cursor) in) positions to the right if 
)n| is positive and |n| positions to the left if |n( is negative. 

<RALK (n( |cursor(> walks |cursor) (n) positions around the 


<DP in) |cursor)> rises through ]n( levels of structure from 
(cursor). 

<DOWH (n| (cursor)> descends through |n) levels of structure 
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fron icursor!. If |n) is positive the cursor is aoved down to the 

right otherwise to the left. 

<SEABCB (pattern) )n| !cursor|> searches for the )n]th 
occurence of an object that Batches (pattern!. If Inj is positive the 
search is to the right, otherwise to the left. 

<FIHD (pattern) in] (cursor)> will conduct the search only in 
the object under (cursor). 

<BEPLACE (pattern) ]x| ]n( |cursor)> replaces )n) occurences 
of objects that Batch (pattern) with the value of |z(. If (n( is 
positive the search is to the right, otherwise to the left. 

<CflAH€B (pattern) )xj )n) )cursor(> changes )n| occurences of 
objects that natch (pattern) with the value of ]xj on the structure 
which is under ]cursor|. 

CIHSEBT -expressions- (cursor)> inserts -expressions- into the 
structure. 

<KILL |n) (cursor)> deletes the expression under the cursor 
and <- in) 1> expressions following it. 
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5. PLANHEB 


The PLAHHEB formalism incorporates a unified set of problem 
solving primitives that ran under a aultiprocess backtrack control 
structure. The foraalisa itself is independent of an; particular 
problea solving domain. The priaitives of the foraalisa make default 
decisions in the course of a computation in those cases where the 
infornation supplied dees not specify exactly what is to be done. 
However, as a natter of principle each priaitive allows a continuum of 
expression froa no preference at all down to the specification of 
exactly one choice. The foraalisa is intended to be used as a aatrix 
in which the necessary domain dependent knowledge can be eabedded. 

Hany of the priaitives rely ov side effects to acconplish their 
purpose. Although the use of side effects is in opposition to sone 
theories of good language design, their use in PLAHHEB has worked out 
well. The foraalisa encourages nodular programming through the use 
of specialized routines to satisfy goals and Bake deductions. 

The naae PLAHHEB comes from the desire to create a foraalisa 
in which it is easy to express plans of action. To construct a plan 
in the foraalisa is the saae as constructing a PLAHHEB theorem. 

Hixing planning and deduction is guite easy. Conditional plans are 
explicitly provided for as is the ability to backtrack in case of 
failure. 

Consider a statement that Batches the pattern IIBPLISS |tj 
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ly|]. The stateaent has several iaperative uses. 

stl: If ve can deduce |x|, then ve can deduce jy|. 

In PLANNER the stateaent stl would be expressed as ANTECEDENT £] |x| 

<ASSERT |y|» which aeans that |x| is declared to he the antecedent of 
a theorem such that if Jx| is ever asserted in such a vay as to allow 
the theorea to become activated then |y| is asserted. 

st2: if we want to deduce ly| # 

then establish a subgoal to first deduce JxJ. 

In PLANNER the stateaent st2 would be expressed as 

<C0NSEQUENT £j HI 

<G0AL |X|> 

<ASSEBT |y|» 

which aeans that |y| is declared to be the conseguent of a theorea 
such that if the subgoal ]x] can be established using any theorea then 
the conseguent ]y| is asserted. 

Be could also assert <C1A0SE £] £ NOT JxJ] |yj > which is a 
clause which says that £aot |xj] or |yj is the case. PLANNER has goal 
oriented prinitives for using and aanipulating all of the above 
variants. For certain purposes any one of the variants can be aore 
useful than the others. Iaperative inforaation and heuristics can 
aore easily he expressed in the procedmral variants. For exaaple 
heuristic inforaation as to when ve should create a subgoal x in order 
to achieve y can aore easily be incorporated into a CONSEQUENT 
theorea. £0n the other hand we can aore easily deduce <CLA0SE £] c 
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d> froa CCLAOSE [ ] x £BOT y] c d>] Of coarse the distinction is not 


sharp since the two kinds of assertions can be coabined by aaking 
assertions about the actions of iaperatives. 
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5. 1 PL AH NEB Forms 


5.1*1 Hierarchical Backtrack control Structure 


PLANNEE uses a control structure in which the hierarchy of 
calls is preserved so that a computation can backtrack to an 
activation froa which it has already returned. Backtracking preserves 
the nesting of block structure. It siaply traverses the stateaents 
executed in reverse order. The primitive functions FAIL and FAILPOINT 
enable the backtrack process to be controlled. The fora <FAIL> 
generates a siaple failure which backtracks to the most recently 
executed fora 

<FAILPOINT +activation-naae+ [-declarations-] 

|expression| 

[|message] jactivation] 3 
-body-> 

Bhere (message] is bound to the aessage of the failure and the 
predicates are evaluated to try to find one which is true. For 
example 


<prog [[x 3]] 


<prog too [] 

<failpoint [] 


• x 

[-."optional"] 

<.foo <_ si 4>> 

;"exit .foo with 4"» 
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;"tbe first tiae through the above expression 

has .x as its value" 

<cond 

[<is? 3 .x> 

<fail>] 

[-."else" 

5 ]»> 

evaluates to <♦ 4 5> vhich is 9. 

The identifier x is declared to be a fixed point integer vhich is 
initialized to 3. The value of <failpoint [ ] .x [-»" optional" ] <_ :x 
4» is 3. Bhen the second argument of the call to is evaluted the 
conditional detects that x is bound to 3 and so generates a siaple 
failure. The failure backtraces to the call to FAILPOIVT with the 
nessage <> vhich is PAI.SE. The identifier x is assigned the value 4 
and the rest of the computation proceeds normally. 

The top level function of PLABMIB is a read, evaluate, print 
loop. Bhen tte expression read is successfully evaluated then the 
mhole hierarchy of calls is forgotten, the value is printed, and the 
process repeats. 

One of the most straight forvard ways to implement 
hierarchical backtrack control structure is through the use of a 
backtrack stack on vhich backtrack information is stored. The only 
tricky point comes in the exdcnton of an exit shere the temporaries 
must be pushed onto the backtrack stack before doing the exit. The 
other straight forvard method of implementation is not to have a stack 
at all but rather to keep all the activation frames is garbage 
collected storage. The stack implementation has the advantages that 
it keeps a smaller vorking set and doesn’t cause garbage collection. 
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The svanp iapleaentation has the advantages that it is conceptually 

cleaner and is aore flexible. The ideal iapleaentation is to be able 
to run either aode. In stack aode the acivation records are siaply 
tuples on the stack. 

The use of backtrack control structure has the iaportant 
fringe benefit that it allows us to debug aore easily, se have 
available the following control praitives. 

<STEP 1p| ]n| (condition|> executes the process |p| for )n| 
eleaentary steps unless the (condition! is net in which case it 
returns the nuaber of eleaentary steps coapleted. If Jn( is negative 
then the process is executed BACKHARDS! This enables us to zero in on 
bugs by running forwards and backwards until the bug is found. 

<IHVCKE (p( |n] (conditions executes the process |p| for (n| 

procedure invocations unless the (condition) is net in which case it 
stops and returns the nuaber of procedural invocations which have been 
coapleted. Again if |n| is negative then the process is run 
backwards. 

5. 1.2 PLANNER Functional Foras 

The functional foras in PLANNEE are FOHCTXCN and ACTOB. The 
sole change in the senantics is that the functional ferns of PLANNER 
can handle pattern directed invocations. 

The following exaaple illustrates the syntax of functional 
foras. The function AflOHG which is defined below is a generally 
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useful PLANNED function. Shat AMONG does is to successively return 

the elements of the structure given as its argument. For example 
<among [E A ]> returns E as its value. But if a siaple failure 
backtracks to it then it returns A as its value and continues the 


computation. But if still another simple 


backtracks then it 


allows the failure to continue to propagate through the function 


AMONG. 


The particular way in which the function AMONG is used here 
does not accomplish anything that cannot be done easily in LISP. He 
give this exaaple because it is siaple enough to be easily understood 
One way to assign to the identifier x the value which is the first 
element of .list that is greater than 5 would be 


<is 


{{?} <all <greater 5> ;x> {?}) 
.list> 


Another way would be <is _x Clarger 5 <aaong .list»> where 


<define 


if 


?! 2 !ipSla'V t llst J < f«9 

<> 

; "establish a fail point and return <>*• 

[m a?] 

;"on backtracking let a be the message and a? be true 

the failure will propagate through" 

<cond 

£<not? <is? .a <>» 

;"if the aessage is not <> 

then restart the failure" 1 

[<is? .a <» 

;"the aessage is <>" 

Crestore .for«ard> 

;"start going forward agai 

. _ with the failpoint restored"]» 

<cona J 

£<eapty? ,list> 
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;"if list is empty generate a 

simple failure out of among" 
<fail <> .munger>] 
r-"else" 

< <linear :first !:iist> ,list> 

;"set first to the first of .list and 

list to the rest of .list" 

<.hunger .first> 

;"exit .lunger vith .first"]»» 


<define larger <function [a b] 

<cond 

[<is? <greater .b> .a> 

;"if a is greater than b then return a" 

.a] 

[-•"else" 

;"otherwise generate a failure with the message <>" 
<fail <»]»> 


Thus the value of <larger <among (2 4 6)> 5> is 6. 


5.1.3 PLANNEE Theorems 

PLANNEE allows procedures to be invoked by a pattern which 

states what the procedure is supposed to accomplish. 

There are four kinds of theorems which are presently defined 

in the language for satisfying requests made in the body of 

procedures: 

1. Consequent theorems for satisfying goals. Consequent 
theorems are the most fundamental in the sense that they can easily be 
used to simulate the other two kinds of theorems. 

2. Antecedent theorems for deducing the conclusions of 
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assertions 

3. Erasing theorems for deducing conclusions from the fact 

that some assertion is no longer true 

il. simplifying theorems are for simplyfying expressions. 


5.1.3.1 Conseguent 

<CCHSIQ0EHT . 

-type- ♦activatxon-namev 

|declaration-specification| 

jconseguent-pa tternI 

-body-> 

evaluates to a procedure which declares that Jconseguent-patternl is 

the conseguent of a theorem which can be used to try to establish 
goals that match the pattern Jconseguent-patternl. Whether or not the 
theorem actually succeeds in establishing the goal depends on the 
body. Typically the first action that a theorem of type conseguent 
takes is to try to reject the goal* We cannot emphasize too strongly 
the importance of analyzing the conseguences of goals in order to 
reject the ones which cannot be achieved. Even if no absurdity is 
detected# the conseguences are often just the statements that are 
needed to establish the goal. The only way that a theorem that begins 
»ith the atom conseguent can be called is by the pattern directed 
call: 


[ <[G0A1 | goal-pattern] ]> 

|recommendation! 
jstate-path| ]> 


<CALL 
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which attempts to satisfy tbe goal Igoal-pattern! where Iconseguent- 
P a ** ern l Batches Jgoal-pattersj and the conseguent theorea is in the 
data base specified by J state-path J. The function COHSBQUBHT is 
defined to be: 

<PORCTIOH ♦checker* *activation—pane* 

[-"PITTBBR" 

k ^ ^ [|declarationsJ [GOAL |consequent-patternJ ] ] j 

The following theorea says that if it is our goal to prove x and we 

have proved that v iaplies x then ve should sake it our goal to prove 
v. 


Consequent [x w] ?x 

Current {iaplies ?v ?x]> 

<goal .w>> 

The following theorea says that two things are egual if they 
identical. 


Consequent [xj [ = ?x ?x ]> 


With this consequent theorea* evaluating the following causes: 


<prog [a] 

;"declare an identifier a n 
<goal [= ?a 3J? 

;"a gets the value 3 since a is linked to the 

identifier x in the consequent theorea"> 

<prog [a cl 

;"declare a and c" 

<prog &b] 

;"declare b" 

<goal [» ?a ?b 3> 
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;**a is linked to b" 

<goal [= ?b ?c]> 

;"b is linked to c"> 

<goal [ = ?A 3]> 

; N a gets the value 3 and so 

therefore c gets the value 3"> 


5. 1.3.2 Antecedent 


<ABTBCED£ST 

♦checker* 

|declaration-specification( 

|antecedent-pattern| 

-body-> 

evaluates to a theorea which declares that |antecedent—pattern| is the 

antecedent of a theoree free which conclusions nay be drawn by the 
body. The theoren can be used to try to deduce conseguences fron the 
fact that a statenent that watches the antecedent has been asserted. 
The only way that a theoren that begins with the atoa antecedent can 
be called is by the pattern directed call: 


<CAtL 

[<[ ASSEBT |assert-pattern|]> 

|recoanendation| 

|state-path|]> 

which draws conclusions fren |assert—pattern) where (assert-patternl 
watches Jantecedent-pattern| the aatecedndent theoren statistics 
Irecoanendation| and the antecedent theoren is in the data base 
specified by (state-path]. The function AHTECEDEBT is defined to be: 


<Ft]HCTI0H ^checker* ♦activation-nane* 

[-."PITT EBB" 

[(declarations! [ASSEBT Jantecedent- 


pa ttemi ]] ] 


-body-> 
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The following theorea says that if we assert soaething of the fora 

[not [implies X I]] then we should deduce X. 

Antecedent [x y] [not [iaplies _x _y]] <assert .x» 

The following theorea says that if soaething of the fora [Barry |x] 
lyl] is asserted then [bachelor |x|] should be erased. 

Antecedent [x y J 

[ Barry x y 1 
<erase [bachelor «x]>> 


5.1.3.3 Brasiag 


<EBASIHG 

-type- 

Jdeclaration-specification] 
j erasing-pa t ter n| 

-body-> 

can be used to try to deduce consequences froa the fact that a 

statement that watches the pattern Jerasing-pattern| has been erased. 
The only way that a function of kind erasing can be called is by the 
expression 


<CALL 

[<[EBASE |erase-pattern|]> 

|recoaaendationl 
{state-pathI ]> 

which expresses the fact that there has been a change in the world 
affecting |erase-pattern| where 1erase-pattern) Batches {erasing- 
pattern! . The functicn EBASX1G is defined to be: 

<POHCTXOH ^checker* ♦actiwation—naae+ 

[-."PATTEBE" 

[|declarations! [EBASE |erasing-pattern)]]] 
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-body-> 

The following theorem says that if something of the form [alive xj is 
erased then [dead x] should be asserted. 


<erasing [x] 

[alive _x] 

<assert [dead .x]» 




5.2 FLAHHEB Functions 
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5.2.1 Data Priaitives 

Soae of the functions in PLANNEB are given below together with 
brief explanations of their purpose Exanples of their use are be given 
immediately after the definition of the priaitives below. The 
priaitives probably cannot be understood without trying to understand 
the examples since the language is highly recursive. In general 
PLAHREB remembers everything that it is doing on all levels unless 
commanded to forget soae part of this information. The default 
response of the language when a simple failure occurs is to backtrack 
to the last decision that it made and to sake another choice. 

<CAHDIDATES 

|kind| |pattern] |state-path|> are the |kind| 
candidates that have the saae coordinates as (pattern] and are in the 
local data base defined by Jstate-pathJ. CAHDIDATES is the basic 
retrieval function for the data base. The candidates can be generated 
incrementally if it is not desired to construct then all at once at 
the beginning. The kind of data retrieved may be: 

CUBBEHT for assertions 

FUHCTICH for functions 
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5.2.1.1 Assertions 

<A SSEET!-TENIAIIVE 

(statement] |rec] £-»"PATH 1 state-path] ] £-«"ALREADT" 
jalready-current ] ]> puts jstatement] in the data base defined by 
|state-path| ar3 tries to dram conclusions according to the 
recommendation ]rec|. Recommendations are optional; the default 
recommendation is £-»"TBI"] mhich says not to try any theorems. If the 
statement is already in the data base then Jalready-current] is 
evaluated. If the value of ]already-current] is -•"REASSERT" then the 
jstatementJ is asserted in the first element of |state-path|. The 
-•"reassert" feature is due to Drem McDermott, otherwise, the function 
ASSEBT causes the statement statement vith properties to be inserted 
in the data base which is the first element of lstate-path|. Then 

<CALL 

£<[ASSERT Jstatement|]> 

] state-pathJ 
JrecJ]> 

is evaluated to draw conclusions from statement. If the call to DBAV 
ultimately fails then ]statement| is removed from the data base. The 
argument ]already-currentj is due to Peter Bishop. The recommendation 
is optional. The value of the function ASSEBT is the arc from the 
state which contains the assertion having as indicator the assertion. 

<assert 

<put 

£ subset a b] 

£difficulty trivial]» 
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asserts that the set a is a sabset of the set b and pat the value 

trivial under the indicator difficulty. 

<ASSEBT!-PEBSISTBHT 

{statement! Irecj [-"PATH | state-path) ] [-»"ALBEAEI" 
lalready-currentj ]> is exactly like ASSEBTI-TEMTATIVE except that 
(statement! is not withdrawn from (state-path! on backtracking. 

Expressions of the for# <CIADSE [declarations] -alternatives^ 
denotes an assertion with variables declared followed by logical 
alternatives. For exanple 


<assert 

Cclause [£<set> x y z]] 

[not [subset lx ?y]] 

[not [subset ?y ?z}] 

[subset lx ?z]» 

asserts in declarative form that the subset relation is transitive for 
sets. In other words it is equivalent to 


<assert 

<clause [[<set> x y z]] 

[iaplies 
[ and 

[subset ?x ?y] 

[subset ?y ?z]] 

[subset ?x ?z]]» 

Another kind of assertion is one which has variables which are 
consumed by being bound For example if we translate the assertion 
that John is somewhere as <assert <closure <clause [] [at John ?x]> 
x»# then <goal [at John store]> causes x to be bound to the atom 
store. Thereafter <goal [at John home]> fails since the identifier x 
was consummed in being bound to the atom store. The above problem was 
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suggested by Gene Charniak. 

w. Bledsoe suggested trying the problen of showing that [all a 
[sone b £p b a]]] follows fron [sone x [all y £p x y]]]. 

<assert <clause [y] [p [xO] ?y]» 

<prog £b] 

<goal <clause [p ?b [a0]]>>> 
b gets the value [xO] 

The expression <clause [y] [p [xO] ?y]> is the assertion Skolen forn 
of the assertion [sone x [all y [p x y]]] where xO is the Skolen 
function for x. The expressions <clause £p ?b [a0]]> is the goal 
Skolen forn of [all a [sone b [p b a]]] where aO is the Skolen 
function for a. On the other hand if we were to try to derive [sone x 
[all y [p x y]]] fron [all a [sone b [p b a]]] we would fail: 

<assert <clause [a] [p [bO ?a ] ?a]» 

<prog [x] 

<goal <clause [p ?x [yO ?x]]»> 

The identifier x cannot be be bound. The nany-sorted cnega order 

/ 

guantificational calculus of PLAHNEB allows for the possibility of 
null donains. For exanple it does not follow that there is a god 
which is a deity if we assune that all gods are deities. That is 
[sone [in g god] [deity g]] does not follow fron [all [in g god] 
[deity g]]« Thus we cannot prove the existence of a god so easily. 
However [sone [in g god] [deity g]] does follow fron [sene [in g god] 
[nythical g]] and [all [in g god] [inplies [nythical g] [deity g]]]. 

<assert [nythical [g0]]> 

<assert 

<clause £[<god> g]] 

[not [nythical ?g]] 
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£ deity ?g]» 

<prog £ £ <god> x]] 

<temprog [ ] 

<assert <clause £] £not £deity ?x]J» 

;"assert that there are no gods which 

have the property of being deities" 
<prog £literal1 litera12] 

<carrent 

<claase 

<all 

£ deity <?>] 
_literal2> 

<?>» 

<current 

<clause 

<all 

£ not £ deity <?>]] 
..literal 1> 

<box»> 


.literal1 
.literal2»> 

;"resolve a clause which contains an elesent 

which Batches £ deity <?>] and 
a singleton clause 
whose eleaent latches 
£not £ deity <?>]] producing 

<clause £ ] £not £aythical ?x]]> which 
is then asserted" 

<prog £ literal1 literal2] 

<current 

<cla use 
<all 

[■ythical <?>] 
_literal1> 

<box»> 

<current 

<clause 

<all 

£ not £■ythical <?>]] 
_literal2> 

<box»> 


.literal1 
• literal2»> 

resolve two singleton clauses; 
one containing 

a positive instance of aythical and 
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one a negative instance. 

this binds x to [gO] and produce a 

clause which is written <box>" 
<current <box» 

;"thus we have derived the null clause which 

is a contradiction*^ 

<assert <clause [] [deity .x]»> 

;"asseft [deity [gO]]" 


5.2.1.2 Erasures 


<ERASE!-TENTAfI.VE 

jstatenentj |rec| [-'"PATH* (state-path) ] [-"HOT-FOUHD" 
jnot-foundl]> tries to find an assertion la) in |state-pathl in the 
data base that Batches ]stateaent). If such an assertion |a| is found 

then it is erased and 

<CAI.li 

[<[ ERASE |a) ]> 

|recoaaendationl 
| state-path j ]> 

is evaluated to assay the iaplications of the change. If no such 
assertion is found then }act-fonnd| is evaluated. If the change 
statenent fails or if a failure backtracks to the function ERASE, then 
|a) is reinserted in the data base and the whole process repeats with 
another statenent froa the data base. The value of the function ERASE 
is an arc froa an eleaent of (state-path] with indicator a statenent 
which Batches (pattern). The reader should be careful not to confuse 
what happens when the function ERASE is called to reaove soaething 
froa the data base with what happens when an ASSBRTIOH fails and thus 
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removes what was asserted free the data base. The function EBASE nay 

atteapt to do pattern directed invocation to deduce consequences of 
the deletion whereas ASSEBT will not. The argnaent Jnot-found| is due 
to Peter Bishop. 

<erase [on-top-of brick 1 brick2]> erases the fact that brickl is on 
top of brick2. 

<EBASEl-PEBSISTEHT 

IstateaentJ tree] [-"PATH" |state-path] ] [-."rot-POOHD" 
inot-found]]> is exactly like the function EBASE!-TENTATIVE except 
that the assertion deleted froa |state-path| is not re-inserted on 
backtracking. 

5. 2.1.3 Goals 

<COBBEHT? 

I pattern] |state—path)> tests to see if a stateaent 
that aatches lpattern] currently is in |state-pathJ. If there is such 
a stateaent, then the identifiers in I pattern] are bound to the 
appropriate values. If there is no such stateaent, then CUBBENT? 
returns false, if a siaple failure backtracks to the function 
CUBBERT, then the identifiers that were bound are unbound. Then the 
whole process repeats with another stateaent in the data base. 

PLARREB is designed so that the tine that it takes to 
deteraine whether a stateaent that aatches pattern is in the data base 
or not is essentially independent of the nuaber of irrelevant 
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statements that have already been asserted. A coordinate of a 

structure is defined by soie atom, number, or string being in some 
position of the structure. Bhen an s-expression is asserted PLIHNEB 
remembers every coordinate that occurs in the s-expression. Tmo 
expressions are similar on retrieval only to the extent that they have 
the same coordinates. The function <HEBGE Jn| Jl|> mill merge |v| 

into the list |1|. Consider the simple assertion 

<assert .z [-*"path w (.si) ]> mhere si is bound to a state and z 

is bound to -»£a £b c]] causes the folioming changes: 


<put 


<position 1 current> 

<merge 


• 3C 

<get a 


<position 1 current> 

(°) 

;"if the bucket is empty then, 

initialize it mith 
an empty list"» ]> 


<put 


<position 1 <position 2 current» 

[b 

<merge 

.z 

<get b 

<position 
1 

<position 2 current» 

(0)»3> 


<put 


eposition 2 eposition 2 current» 

£c 

emerge 

.2 

eget c 

eposition 
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2 

<position 2 current» 

( 0 ) »}> 


<put .si r .2 -•"asserted" 1> 

Classes are stored in tuckets under the position -"class". Thus the 

assertion <assert ,w [-."path" (.si) ]> where w is bound to [nonempty 
<class e f>] would result in: 



<put 


<put 


<position 1 current> 

[ncneapty 
<aerge 

.w 

<get noneapty 

<position 1 current> 

( 0 ) 

;"if the bucket is eapty then, 

initialize it with 
an eapty list"»]> 


<position —"class" <position 2 current» 

[e 


.w 

<get e 

<position 

-"class" 

<position 2 current» 

( 0 )» ]> 

<put 

<position -"class" <position 2 current» 

[f 

<aerge 

• w 

<get £ 

<position 


<put .si £.w -"asserted"]> 
are classes at their top level. 


<position 2 current» 

(0)»J> 

For exaaple the clause 








TREE - STRUCTURED WORLDS 



ASSERTED 


INITIAL WORLD WITH B ON A WHICH IS AT POSITION PI 



ERASED 


PUSHED DOWN WORLD WHERE B HAS BEEN MOVED TO THE 
LEFT OF A. NOTE THAT A IS STILL AT PI FROM THE POINT 
OF VIEW OF THIS WORLD. HOWEVER B IS NO LONGER ON A. 
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Cclause [] [not [on a b]] [on a c]> would be stored under the 

coordinates for [not [cn a b]] and [on a c]. Variables in expressions 
are ignored on indexing. Thus two expressions which are the saae 
except for change of variables are considered equivalent. Hhen the 
bucket under scae coordinate exceeds a threshold then the bucket could 
be sub-divided by taking the coordinates by pairs. The only reason 
that we don*t store statements under all the possible ccnbinations of 
coordinates is that we can not afford to use that auch space. Storing 
the most recent assertion at the front of a bucket also tends to speed 
retrieval. If a total ordering is imposed on the assertions, then the 
buckets can be sorted. Richard Greenblatt has constructed a clever 
total, ordering on the assertions which also has the advantage of 
storing new assertions at the front of the buckets. The total 
ordering is constructed incrementally as assertions are made, if 
HATCHLESS had an efficient parallel processing capability tnen the 
retrieval could be even faster since we would do the look-ups on 
coordinates in parallel. Re night imagine a machine with multiple 
program counters each cf which is capable of interrupting the 
execution of the others. However, with the current technology it 
appears more economical to timeshare a few very fast physical 
processors. clauses are stored in a special way for efficiency. The 
value of the expression <CUBREHT I pattern! |state-pathf> is an arc 
from the skate in (state-path| which contains the assertion with 
indicator name being an assertion that matches |pattern!. 
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<current? 

[subset a b] 

[-»"use" <has [difficulty trivial]>]> 

is true only if it has been proved that a is a subset of b with the 
value trivial under the indicator difficulty* We shall use the prefix 
operator ?x for <GI¥EH x> to denote variables of the guantificational 
calculus. The concept of a variable is different fron that of an 
identifier in that variables have global scope. 


given: 


<assert 

<put 

<cla use [[<object> xj [<set> y z]] 

[subset [f ?x] ?y] 

[subset ?y ?z]> 

[difficulty hard]>> 

The above statement says that for all objects x and sets y z that £ £ 
x] is a subset of y cr y is a subset of z. evaluate: 


evaluates 


<prog [[<set> * u] ] 

<current 

Cclause [subset _w _uJ <?»» 


to <clause 

£[<object> x]3 

[subset [f ?x] £f ?x]]> 

v gets the value [f ?x] 
u gets the value [f ?x] 


<CUBRENT 


(pattern| |state-pathJ> is exactly like COBREHT? 
except that if it runs out of objects that are currently in Jstate- 
path] which natch |pattern| then it generates a simple failure instead 
of returning false. The value of CORBEBI is the node which is the 
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property list of an assertion in |state-path{ which natches {pattern] 

<6011 

|goal-pattern| irecj [-"PITH" {state-path| ]]> tries to 
achieve the 1 goal—pattern} according to a reconnendation (reel* 
Becoaaendations are optional; the default reconnendation is f^uSE" 
-» H CUBBENT" <?>] which neans the data base is searched to see if there 
is senething already proved which natches {goal—pattern} then use it 
otherwise try any consequent theoren whose consequent natches {goal- 

pattern}. The reconnendation }rec{ nust be of one of the following 
two forns: 


Is £ -»• CSE" 

-"C0BBBEBT" 

-pats-] is equivalent to 

<C0HD 

[<C0BBEHT? (goal-pattern) )state-path|>] 

[-."ELSE" 

<CiLL 

£<£ GOAL ]goal-pattern| ]> 

£-."0SB* -pats-] 

(state-path) ]>]> 

2; £-.»0SB1" 

-•"CDBBBHT" 

-pats-] is equivalent to 

<C0ID 

£<CtJBBBHT? }goal-pattern 1 |state-path|>] 

£-."ELSB" 

<C1LI 

£<[6011 {goal-pattern J ]> 

£V»0SB" -pats-] 

(state-path)]>]> 

The -."0SE1" reconnendation is due to Pat linston. hlan Kay has 
suggested that the syntax of PllMHBB could be easily changed so that 
every expression is a goal.Thus instead of writing <6011 x> we would 
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siaply write x. Alan's suggestion has the aerit that it siaplifies the 
language. One reason that we do not do this is that pattern directed 
invocations are soaewhat aore inefficient than straightforward calls 
in which the naae of the called function is explicit. Anyone who 
prefers the other syntax can easily expand all function calls <f args> 

into <£f args]> by a trivial macro. 

Suppose that we know that zero is an integer and that if n is 
an integer then o+t is an integer. He would like to find an integer j 

which is not zero. 


<assert £ integer 0 ]> 

<assert <conseguent £n] _ 

{integer £♦ xn 133 

<goal £ integer ?n ]»> 


< pr og [[<-y> ^j get Jj3>> 


j gets the value £♦ 0 1] 


<GOAJL? 


|goal-pattern| |rec| £-» w PATH w Jstate-pathJ ]|> is 
exactly lieke GOAL except that it returns <> instead of backtracking 
if it runs out of alternatives. 

<GCAIS> 


returns as its value a list cf the specifications of the currently 


active goals. 

<SOBGOAL 

—clauses—> attempts to Batch the first element of each 
clause in turn to the elements of the list of currently active goals. 
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If tte first element of a clause Batches then execution continues with 
the remaining elenents of that clause. 

5.2.2 Control Primitives 

<S HITCH 

|new-state-path| jexpression)> evaluates |expression) 
using the Jnew-state-path! to do retrievals froa the data base. At 
any given tiae PLAHHEB expressions are being evaluated in a state 
path. A top level process begins by using the priaary data base as 
iis state, it can switch into a local state by using the the function 
SHITCH. Tree structures of local states can be created by using the 
function STATEPROG. states can be conceptualized as a linear list of 
changes to the data base. Thus there can be several incoapatible 
states of the world simultaneously under consideration. Although the 
htee structure of the local states can be conceptualized as a linear 
list of changes, it is actually iapleaented aore efficiently so that 
the retrieval tiae for assertions is essentially independent of the 
size and number of local states. The assertions in the data base are 
tagged as to which states they are in. 

<STATE> 

returns as its value a new local state. 

<PBIHABI> 

is the priaary state of the systea. 


<OPDATE 
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Istateli Jstate2J> updates lstatell into |state2|. If 
the second argument is missing the global data base is assumed. 

<G ATE 

|x1> is the value of Jxl unless lx| fails simply in 
mhich case it is <>. the expression SJX| is an abbreviation for <GATE 

Ul>. 


!*<block (<oblist gate!-> <oblist>)> 

<define gate <function out [*x] 

<failpoint £] <> 

[message activation?] 

<cond 

[<nct <or .message .activation?» 
;"neither the message nor 

activation are on" 
<.out <» 

;"exit gate vith false"]» 

<eval .x> 

;"the value of gate is the value of .x unless 

the evaluation of x fails» 

!X<end-block> 


<cond £-»"else" <fail>]> fails with the message <>. 

<cond [<fail> 3] [-"else" 7]> fails 

<cond [S<fail> 3] [--"else" 7]> evaluates to 7. 

<cond [<> 3 ]> evaluates to <>• 

<cond [<> 3] [-»*else" 4]> evaluates to 4. 

<cond £^»"else" <fail>] £-»"else" 5]> fails. 

<cond f&Velse" <fail>] £-*"else" 5 ]> evaluates to 5. 


<TEHPBOG 

♦checker* ♦activetiog-name* [-declarations-] -body-> 
is like the function PBOG except all assertions and erasures that are 
made within the scope of the function TEHPBOG are undone when the 
function TEHPBOG returns. The function TEHPBOG is useful for dealing 
with hypothetical. suppose that we wanted to establish [all x [p x]j 





HITLER WOULD »■ 
TO INVADE ENGl 



[NOT [ INVADE 
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b mathematical induction. 


<goal £p 0]> 

;"first try to prove [p 0]" 

<temprog [k <arbitrary <integer»] 

;"let k be an arbitrary integer" 

<assert £p . k]> 

;"assert that p holds for k" 

<goal [p i*<♦ .k 1>]> 

;"try to prove that p holds for k-*1"> 

<SWITCH 

|state-path| JexpressionJ> causes Jexpressionl to be 
evaluated with |state-path| as its current local state path. The 
value of PATHi-STATE is the current state path. local states are 
useful for handling contra-*to-factual conditionals and for 
simultaneously manipulating inconsistent states of the world* 
Assertions affect only the state which is the first element of the 
state path in which the assertion is evaluated. The following assigns 
the identfier si the value which is a local state path in which Hitler 
invaded England. 


<switch 

<_ :s1 £<state> !.path!-state]> 

<assert [invade Hitler England]» 

We further suppose that Hitler is cra2y. This could be expressed by 
doing the assertion within si and assigning the result to s2: 


<switch 

<_ :s2 £<state> !.s1]> 

Cassert [crazy Hitler 3» 

How if we ask if Hitler is cra2y in the state path si, the answer is 
that he is not; but he is crazy in the state path s2. 
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<switch .si Ccurrent [crazy Hitler ]» fails 
<switch .s2 <current [crazy Hitler j» is true 

<switch ,s2 Ccurrent [invade Hitler England1» is true 
Cswitch 

[<1 .s2>] 

<curreat [invade Hitler England]» fails 

Cswitch 

[<1 .s2>] 

<curcent [crazy Hitler ]» is true 

<svitch 

[<2 .s2> <1 .s2>J 

<current [crazy Hitler ]» is true 

Erasures affect the first local state of the state path in which they 
are evaluated. After 

<switch .si <erase [invade Hitler England ]» ve have 


<switch .si <current [invade Hitler England]» fails 
<switch ,s2 <current [invade Hitler England ]» fails 

If we know that a fornula of the forn [or Ul lyl] is true and 
we want to establish a goal of the forn Jgj then we could write: 


CPBOG [J 

CTEHPBOG [J 

CASSBB1 ]X|> 

CGOAI Jg|» 

CTEHPBOG [J 

<ASSIST y> 

<GOAL 1g)» 

CASSEBT |g|>> 

The above fori of disjunction elimination is often used when y is of 

the fori [HOT 1*|j. Goals of the fori [or jxj |y|] can be established 
as follows: 


<PBOG [] 

CTEHPBOG [ ] 

<ASSEBT [MOT J*| ]> 
<GOAL y» 

<ASS2BT CCLA3SB [ J |x| |y|»> 
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5.2.2.1 Failure Primitives 


<UHIQ0E> fails if the current goal is not unique among all the 
goals that are currently active. 

< UNI QOE 

<|p| -args-> Jplace|> fails if the procedure |pl with 
arguments -args- is not unique among all the procedures that are 
active in ]placef. The (place] can be a process or it can be [BETWEEN 
Inamel] ]name2|] in which case only the procedures between Inamel] and 
]name2| are be examined. 


CHETRX 

]activation|> causes failure to (activationl which 
must include the call to BETSY within its scope. Execution resumes 
with the beginning of the named block. 


<prog here [a] 

<_a 3> 

<prog there [J 

Ccond 

[<is? 4 .a> 

<.here «a> 

;"exit .here with .a"]> 

<_ :a 4> 

<retry .there»> evaluates to 4 


5.2. 2.2 Finalize pri 
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<FINALXZE 

tactivatios*Qaae>> causes aXl actions that have been 
tskco In the block ^activation—naiet to be finalized and then returns 
the value of ♦activation-naae+. Thus «FIHA1LIZE +activation-nane+> - 
values-> sill finalize all the actions that have been taken in the 
scope of +activation-nane* and then exit +activation-nane+ with - 
values-. Actions which are finalized are not undone if a failure 
backs up. Finalization can be used to save storage for actions which 
should not be aatcnatically reverted in case of failure. For exaiple, 
robot thinking for a given task is often divided into two phases: a 
planning phase and an action Dhase. In PIAHBEB this is typically done 
by having the planning phase return as its valne a PBOCEDUBE which is 
to be executed in the action phase. Assertions which record events 

' - . ..... . fV v •- ’i'l f' r-^V •\ -• ;.y;.' ' S’X • ’ 

which have taken place in the "real world" should be finalized in the 
action phase as they happen. 

5.2.2.3 Bepetition Priaitives 

<FOB 

♦checker♦ ♦activation-naae+ {-declarations-] 

[-for-specifications- 

[^"COBBEHT" (pattern) Jstate-path)]] 

-body-> 

is the for statenent of PLAHBEB. For each assertion in the data base 

that latches )pattern) the -body- is executed. For exaiple the 
following statenent places all the bricks on brick1 in the blue box. 

U<brick> x]] 


<for 
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[[-*"current" [on-top-of _x brickl]]] 
<pick-cp . x> 

<place-in <* [blue box]»> 


<PEBSIST 

♦checker* ♦activation-naae* [-declarations-] 
[[-."IHITIAL" -initial-action-] 

[-•"TEST" (test) -test-action-] 

[-•"LIST" jitenl condition] 

[-•"STEP* -step-action-] 

[-"FIH1L" -final-]] 

-body-> 

where ♦activation-naae* and ♦checker* are optional Is equivalent to 
the followings 

<PB0G ^checker* ♦activation-naae* 

[-declaretions- 
[ COLLECTED ()]] 
j"initialize COLLECTED to [] 

<FAI1PCIHI 

[BESSAGE ECTIVATIOH] 

<COHD 

[<HOT? <oa? 

•BESSAGE 
. ACTIVATIOH» 

-final- 

<.factivation-na■€♦ 

•CCLLBCTED> 

;"exit •thctivation-naie* with 
•collected"]» 

-body-. 

<COHD 

[[test| 

-test-action- 

<.♦activation-naae* .COLLECTED> 

5 "exit .♦activation-naae* 

with .collected"]> 

<COVD 

[|condition| 

;*if the condition is net 

then add itea 

to the end of COLLECTED" 
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<_ :COLLECTED (!.CCLL1CTED item)>]> 
-step-action- 

<FAIL> 

;"generate a simple failure"> 

"Are all the blocks in boxl green?" translates to 


<persist bl f[<block> bll 

[[^"tinal" <.b1 t> ;"exit .bl with t"]l 
<goal [in _b boxt]> 

;"find a block in box I* 

<cond 

[6<goal [green .b]> 

;"if the block is green then 

continue with the loop" 1 

[-."else" 

<fail <> ,b1> 

;"otherwise generate a failnre out of 

the persist loop"]» 




<F1HD 

♦activation-name* 

[-declarations- 1 

C 

£-'"QDAHTITI ]quantity| ] 

["•"LESS" |lower-bound| -fewer-1 
[-."GBIATIE" inpper-boundi -more-l]] 
litenj JJ 

-body-> 

constructs a list of between |lower| and |upperJ iitenis according to 


the |body|. The FIHD primitive function is equivalent to the 
following: 


<STBAIGHTEH <PBOG ♦activation-nanev 

[-declarations- [BUBBEB 0] [COLLECTED Oil 
<failpoint £] <> [H A] J 

<COHD 

[<H0T? <Ofi? .8 . A>> 
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<COHD 

[<80T? <IS? 

Iguantity| 
-'"ALL">> 

<FAIL> ]> 

;"if the guantity sought 

is oot all 
then backtrack" 

CCOHD 

[<IS? 

<L£SS |lower-bound|> 
.NOHBEB> 

-less- ]> 

<.+activation-name* 

.CCLLECTED> 

;"return with the items 

collected"]» 

-body- 

< :COLLECTED {!.COLLECTED litem|)> 

<IHC!—PEBSISTEHT HUMBEB> 

<COND 

[<IS? Iguantity| .80HBER> 

<.♦activation-name* .CCLLECTED> 

;"if have found the guantity 

desired then return them"]> 

<CCHD 

[<IS? <GBEATER Jupper-bound I> .NUMBEB> 
-more- ]> 

<FAIL»> 

•Find three boxes that contain green blocks." 


translates to: 


<find [[<box> 

<goal 

<goal 

<goal 


x] £<block> bJ3 [[-"C0ANT1TY" 
[box _x]> 

[contains .x _b]> 

[ green . b ]» 


3]] .x 


5.2.2.4 lulti-Process Primitives 


In more complicated situations # we find that it is convenient 
to be able to have more than one PLABHEB process. 
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<FAIL 

|»essage| 1 placeJ (function|> generates a failure with 
message* to the |placel at the last point that execution left 
fplacei. if the process which called FAXL is ever resuned with 
arguments, then it begins by applying Jfunction! to the arguments. 


<EXHAUST 

♦checker* +activation-na«e+ [-declarations -1 
££“•"INITIAL'' -initial-action-] 

[-•"TEST" J test! -test-action-3 
[-"ACTION" -action-] 

['•"LIST" ]iteaj (condition!] 

[-."STEP" -step-action-] 

[-."FINAL" jfinalj]] 

-body-> 

attempts to execute -body- once for each tine that -action- i 


successfully evaluated. Every tiae that the body it executed the 
function EXHAUST sends a sinplc failure to the action to see if it has 


any alternatives. An EXHAUST loop is very nuch like a PEBSIST loop 
which is defined above. Both loops are driven by the failure 


■echanisn. The main difference is that the effects of executing the 
body of a PEBSIST loop are not preserved because a failure nust 


propagate through the body before it can be executed again, in an 
EXHAUST loop a separate process is created for the action so that the 

effects of executing the body can be preserved. The function EXHAUST 
is eguivalent to the following expression: 


<PBOG ^checker* ♦activation—sane* 

£ 

[COLLECTED () ] 

£<proc> 

£ACTIOB-PBOCESS <PBOCESS ,ACTIOH-FOICTICN>] 
[TAL-PBOC <• ACTION-PIOCESS <PBOCBSS»]]] 
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{"declare COLLECTED to be initialized to [ ]" 

ACTICN-PBOCISS is the nate of the 

process which is to be exhausted by failure" 

{"start the ELANNEB process .ACTION-PROCESS in 

which the action is executed with 
the name of this process 

as an argument so that it can later resume 
this process" 

;"we expect one value to be returned 

which we shall call VAL-PROC" 

<REPEAT [] 

<COND 

[<IS? EXHAUSTED .VAl-PBCO 
-final- 

<.b .COLLECTED? 

{"exit .b with .collected"] 

[|test J 

-test-action- 

{"if the test is met 

then execute the test-action" 

<.b .COLLECTED?]> 

-body- 

<COND 

[lcondition| 

SCOLLECTED (!.COLLECTED |iteml)>]> 
j"if the condition is met then add the item to the end 

of the list of collected items" 

<FAI1 

<? 

• ACTIC N-PBOCESS 

<FONCTION [Y 3 <_ SVAI-PBOC .Y??? 

{"suspend 

execution of the current process 

and begin failing from the point within 

the action process 

where execution last left off"?? 


The following function is defined so that we can start off the 
evaluation or the action process. 


<DEFXNE ACTION-FUNCTION 

[FUNCTION [£<proc> MAIN]] 

<FAILIHG? [<?? <• MAIN EXHAUSTED?]? 

{"when the action finally is exhauseted 

resume the process .MAIN with the value EXHAUSTED and 

terminate the action process" 

-action- 
<.MAIN SUCCESS? 

{"resume the main process with the value SUCCESS"]? 





Suppose that we want tc disprove a proposition „p using likely 

counterexamples. Furthermore we would like to work on each 
counterexample in parallel as it is found. 

<exhaust disprove [c] 

<goal [likely-counter-example _c ,p]> 

-<l<ccnd 

[S<goal ,c> 

<temporize 

.disprove> 

-*"found-counter-example"» ]» 
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5.3 Clauses in PLAHHEB 


We would like to explore the potentialities for using PLASHES 
to control a resolution based deductive system. Since the guestion 
whether or not a given foraula is a theorem or not is undecidable, a 
complete proof procedure using resolution for the first order 
guantificational calculus must in general be rather inefficient, in 
fact any uniform proof .procedure for the first order guantificational 
calculus can be sped up by an arbitrary recursive function for almost 
all proofs. The result on the necessary inefficiency of a complete 
proof procedure should be sharpened up. Mew theoretical tools ®ust be 
developed in order to make any substantial advance on the problem. 

The importance of resolution as a problem solving technigue does not 
lie in the fact that it appears to be the fastest known uniform proof 
procedure for first order logic. Bather, resolution provides one 
technigue for dealing with the logic of disjunction and instantiation. 
Domain dependent procedures must provide most of the direction in the 
computation to attempt to prove a theorem. Se shall introduce new 
actors to match clauses: 

<CLA0SB 

-patterns- |rest-of-disjunctsl> matches a clause only 
if it has disjnncts which match -patterns- and the rest of the 
disjuncts natch the pattern jrest-of-disjunctsl. 
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<prog £ y ] 

<_ 

<clause [subset a :y]> 

<clause £x] [subset ?x b]»> 
y gets tbe value b 
x gets tbe value a 

<CLAOSE-OF 

I pat| |dis juncts-that-iatch-pat J 1 rest-of-disjuncts|> 
Batches a clause such that the clause of the disjurcts that Batch 
jpatj in turn Batch the pattern |disjuncts-that-natch-pat] andthe 
clause of the the rest of the disjuncts Batch (rest-of-disjuncts|. 

The following functions are used to aasipulate clauses. 

<CLAUSE 

[-declarations-] -disjuncts-> returns a copy of a 
clause with the variables declared. 

VARIABLES 

(clause|> returns the variables in the clause. 
<IHSTAHTIAT£ 

(clause(> returns a copy of the clause with all of its 
variables instantiated with unique constants of the appropriate type. 

<RESOLVE 

-clause-specifications-> results in resolving the 
clauses represented by the clause specifications together to yield a 
clause which is returned as the value of the function resolve. A 

clause specification is the literal of the clause which is to be 
unified. 
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<P0R'-8ES0L¥EMT 

♦checker* ♦activation-naie+ [-declaratirons-] 

[[ CLAUSES" -clause-specifications- ] 

[-•"RESOLVENT" | resolvent | ] 

-for-loop-specifications-] 

-body-> 

attempts to execute the body of the for statement once for each result 
of resolving clauses that ieet the clause specifications to produce a 

clause which satches the pattern resolvent* 

It is possible for PLANNER to run out of things to evaluate 
before it has deduced the null clause* A coiplete proof procedure 
could be called to try to finish off the proof. If in the course of 
its operation# the complete procedure generates a clause that latches 
the antecedent of a theorei then PLANNER can be re-invoked. The 
coiplete procedure could be run in parallel with PLANNER. Thus using 
PLANNER we could iipleient a coiplete proof procedure. The point is 
that iipleienting any "reasonable" proof procedure should be easy in 
PLANNER. However# we should not rely on a unifori proof procedure to 

solve our probleis for us. 




SNAPSHOT NO. 




































SNAPSHOT NO. 
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5.4 A Simple Example 


5.4.1 Using a Consequent Theorem 


Suppose that we know that [subset a b], [subset ad]# [subset 
b c] # and [all [functicn <bccle> [[<set> x] [<set> y] [<set> z]] 
[implies [and [subset ?x ?y] [subset ?y ?z]] [subset ?x ?z]]]] are 
true. How can we get PLANNE8 to prove that [subset a c] holds? He 
would give the system the following theorems. 


given: 

[subset a b] 

[subset ad] 

[subset be] 

<assert <define backward ,, , , „ „ , 

<conseguent [[<set> x y z]] [subset ?x ?z] 

<unigue> 

;**the current goal must be unique** 

<goal 

[subset ?x ?y] 

r-.*»use** -»’*current** backward <?> ]> 

<goal 

[subset .y ?z] 

[-."use" -»"current" backward]> 

<assert [subset .x .z] [-""try" <?>]»» 

Now if we ask PLANNER to evaluate <goal [subset a c]> then we obtain 
the following protocol: 
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<goal [subset a c]> 

<current [subset a c]> 
fail 

<achieve [subset a c ]> 
enter backward 
x becomes a 
z becomes c 
<unique> 

<goal [subset a ?y]> 

<current [subset a ?y ]> 

node 1,9 

y becomes d 
<goal [subset d c]> 

<current [subset d c ]> 
fail 

<achieve [subset d c ]> 
enter backward 
x becomes d 
z becomes c 
<unigue> 

<goal [subset d ?y]> 

<current [subset d ?y ]> 
fail 

<achieve [subset d ?y ]> 
enter backward 
x becomes d 
z becomes ?y 
<unique> 
fail 

fail 

node 1,9 ;note that this node appears above 

y becomes b 
<goal [subset b c]> 

<current [subset b c]> 

<assert [subset a c ]> 
succeed 

After the evaluation the data base contains: 

[subset a b] 

[subset ad] 

[subset be] 

[subset a c] 

In other words the first thing that PLAHHBS does is to lcck for a 
theorem that it can activate to work on the goal. It finds backward 
and binds x to a and z to c. Then it makes [subset a ?y] a subgoal 
with the recommendation that backward should be used first to try to 
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achieve the subgoal. The system notices that y might be d, so it 

binds y to d. Hext [subset d c ] is made a subgoal with the 
recommendation that only backward be used to try to achieve it. Thus 
backward is called recursively, x is bound to d, and z is bound to c. 
The subgoal [subset d ?y ] is established causing backward to again be 
called recursively with x bound to d and z determined to be the same 
as what the old value of y ever turns out to be. But now the system 
finds that it is in trouble because the new subgoal [subset d ?y] is 
the same as a subgoal on which it is already working. So it decides 
that it was a vistake to try to prove [subset d c] in the first place. 
Thus y is bound to b instead of d. Now the system sets up the subgoal 
[subset be] which is established immediately. We use the aboye 
example only to show how the rules of the language work in a trivial 
case. If we were seriously interested in proving theorems in PLANNER 
about the lattice of sets, then we would construct a finite lattice as 
a model and use it to guide us in finding the proof. 

5.4.2 Dsiag an Antecedent Theorem 


Suppose we give PLANNER only the following theorems. 


given: 

[subset a b] 

[subset c d] 

<assert <define forward-right 

Antecedent [[<set> x y z]] [subset _y _z] 

<goal [subset ?x . y]> 
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[subset .x . z] 

[-•"try" forward-right forward-left ]»» 

<assert <define forward-left 

Antecedent [[<set> x y z]] [subset __x _y ] 

<goal [subset ?y , z]> ~ ~ 

<assert 

[subset .x .z] 

[-•"try" forward-right forward-left]»» 

How if PlAHHEB is asked to the theorea evaluate <assert [subset be] 

[-•"try" <?>]>, we obtain the following protocol: 


<assert 



[subset b c]> 

<draw [subset t c ]> 
enter forward-right 
y becoaes b 
z becoaes c 
<goal [subset ?x b]> 

<current [subset ?x 
x becoaes a 
<assert [subset a c ]> 

<drav [subset a c]> 


enter forward-right 
y becoaes a 


b]> 


z becoaes c 

<goal [subset ?x a]> 

<current [subset ?x a]> 
fail 

enter forward-left 
x becoaes a 
z becoaes c 
<goal [subset c ?z ]> 

<proved [subset c ?z]> 
z becoaes d 
<assert [subset a d]> 

<draw [subset a d]> 
enter forward-right 
y becoaes a 
z becoaes d 


<goal [subset ?x a]> 

<current [subset ?x a]> 
fail 

enter forward-left 
x becoaes a 
y becoaes d 
<goal [subset d ?z]> 

Ccurrent [subset d ?z]> 
fail 
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fail 

succeed 

After the evaluation the data base contains: 

[subset a b] 

[subset c d] 

[subset ad] 

[subset be] 

[subset a c] 

Theorems in FLANKER can be proved in auch the sane way used 
for ordinary theoreas. For example suppose that we had the following 
two theoreas: 

<assert <define th4 <censeguent [[<set> a c]] [subset ?a ?c] 

<goal [set ?a]> 

<teaprog [[<cbject> [x <arbitrary <object»]J] 

<assert [eleaent .x .a] <?» 

<goal [eleaent .x ?c ]» 

<assert [subset .a .c] <?>»» 


The function ARBITRABI generates a unique syabol which has the type of 
its arguaent. On entrance tc the function TEHPROG the identifier x is 
bound to a freshly created syabol. The above theorea is a 
constructive analogue of 

[all [function <boole>[[<set> a] [<set> c]] 

[implies 

[all [function 

<boole> 

[[<object> x]] 

[iaplies [eleaent ?x ?a][eleaent ?x ?c]]] 
[subset ?a ?c]]]]] 


Going in the opposite direction# we have 


<assert <define th4-5 <antecedent 

[[<set > a b] ] 

[subset a b] 

<assert 


<antecedent 
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[eleaent ?x ?a] 

<assert [element ?x ?b ] <?» a»>» 

Assert <define th4-6 Antecedent 

[[<set> a b]] 

[subset a b] 

Assert 

Consequent 

[[<eleaent> x]] 

[eleaent 7x ?b] 

<goal [eleaent ?x ?a]> b»»> 


Assert <define 

th3 

Consequent [[<object> xj[<set> r s]] 

[eleaent ?x ?s] 

<goal [eleaent ?x ?r]> 

<goal [subset ?r ?sj> 

Assert [eleaent .r .s] <?»»> 
The above theorea is a constractive analogue for 


[all [function 

<boole> 

[[<object> x] [<set> s]J 
[iaplies 

[soae [function 

<boole> 

[[<set> r]] 

[and [eleaent ?x ?r] [subset ?r ?sl]1 
[eleaent ?x ?s}]]]] 

Froa th3 and th3 *e can prove the following theorea: 

Consequent [[<set> a b cl] [subset ?a ?c] 

<goal [subset ?a ?B]> J 

<goal [subset .b ?c)> 

Assert [subset .a .c] <?»> 

The above theorea is a constructive analogue for 

[all [function 

<boole> 

[ [ Aet> a J [ <set> b] [<set> cl] 

[iaplies 

[and [subset ?a ?b] [subset ?b ?c]] 

[subset ?a Tc]]]] 
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Often we treat the stateaent of a theorea siaply as an abbreviation 
for the proof of the theorea. 

He would like to examine the previous problea from the point 
q£ view of resolution based deductive systen. The actor CLAUSE natchs 
clauses. It uses the fact that disjunction is coaautative and 
associative. He have: 


1 . <clause [[<set> a b] [<object> x]] 
[not [subset ?a ?I>]3 

[not [eleaent lx ?a]j 

[eleaent ?x ?b]> 



[subset ?a ?b]> 


3. 


<clause [[<set> a bjj , , , K11 

[not [eleaent [eieaent-of-difference ?a ?b] ?b]3 

[subset ?a ?b]> 


0 


ssert <define necessary 
<antecedent 

[literal! Iiteral 2 ] 
<clause <all [subset 


(?) ] _literal!> <?» 



<clause 


<all 

[not [subset (?) ]] 
_literal 2 > 

<?» 

<clause [[<set> a n] [<object> x]] 

[not [subset .a .b]] 

[not [eleaent ?x .a]] 

[eleaent ?x •b]» 

<assert <resol»e .literal! .Iiteral 2 »»> 


The above tkeocea says that we should eliainate all positive instances 

of the predicate subset froa clauses. It is a special case of 
theorea! which has been partially coapiled. 



5.4 page 248 

<assert <define sufficient 
Antecedent 

[[<set> a bj literal 1 ] 

% clause <all [not [subset a bil literal 1 > <?» 

<prog [literal 2 J 

<_ x 

<clause <all [subset (?) 3 litera! 2 > <?» 
<clause [[<set> a b 33 

[subset .a ,b 3 
[eleaent 

[eleaent-of-difference .a .b] 

.a3» 

<assert <resolve .literal 1 .literal 2 >» 

<prog £literal 23 

<_ 

<clause <all [subset {?} 3 literal 2 > <?» 
<clause [[<set> a b 3 3 

[subset .a ,b 3 
£Dot [eleaent 

[eleaent-of-difference .a .bl 
• b33» 

<assert <resolv* .literall .literal 2 »>;>» 


The above theorea says that ue should eliainate all negative 
of the predicate subset froa clauses. 


instances 


5.4.3 Using Besolution 


Be shall assnae that the resolution routines auteaatically 

detect contradictory pairs of clauses uhen they are generated. The 

theorea [iaplies [and [subset a b3 [subset b c33 [subset a c33 can oe 
proved as follows: 


<prog £ 3 

Cteaprog £[<set> 

[a <arbitrary <set »3 
£ b <arbitrary <set»j 
[c <arbitrary <set »]33 

<assert <clause [3 [subset .a *b!> [•"•"try*' <?> 1 > 

<assert <clause [3 [subset .b .c 3 > [-"try** <?>]> 
<assert <clause [ 3 [not [subset .a ,c}3^ [“•"try" <?>j> 
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<goal <clause»> 

<assert <clause [[<set> x y z]] 

[not [subset ?x ?y]] 
[not [subset ?y ?z]J 
[subset ?x ?z]»> 


The proof is: 

aj] [element ?x b]> by 1. and 4. 

b 3 3 [element ?x c]> by 1. and 6. 

8 . <clause [] 

[not [subset a cjj> 

9. <clau ^| 1 ^ nt [ e le»ent-of-difference a c] a]> by 8. and 2. 

^ [element [element— of—difference a c] b}> bv 8. and 3. 

11. [ele Bent-of-difference a c] c]]> by 10. and 7. 

12. <cla f®® t ^ eleBent [element-of-difference a c] b]J> by 9. and 5. 

13. <clause []> by 12. and 19. 


H. stiausc 


[subset a b]> 

5. <clause [[<set> x]l 

[not [element yx 

6. <clause [ ] 

[subset b c ]> 

7. <clause [[<set> x11 

[not [element ?x 
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5.5 Myths about PLANNEE 

5.5.1 Consequent Theorems Are Osed Only for Working Backwards 

we would like to give an example to show that the computation 
tree that ELAN NEB defines as it executes theorems does not necessarily 
correspond to the tree of the intuitive solution space which is being 
investigated. The example which we use is the farmer, goat, cabbage, 
and wolf problem. We worked out the following solution with Jeff 
Bulifson. The problem begins with a farmer on the side of a stream 
with a boat, a wolf, a goat, and cabbage. The farmer wants to 
transport them all across the stream in the boat. The boat can only 
hold one of them besides the farmer. The wolf will eat the goat and 
the goat will eat the cabbage if the farmer is not there to interfere. 
How can the farmer get them all across the strean? We begin by 
evaluating <goal [frcm t t t t]> which means to set up a goal to make 

a move from the postion where all four objects are on the sane side of 
the bank. 


<assert <define make—move <conseguent make 

[wolf goat cabbage farmerJ 
[from ?wolf ?goat ?cabbage Tfarmer ] 

<goal [safe .wolf .goat .cabbage .farmer]> 
;"make sure the current situation is safe" 
<cond 

[<and? 

<is? <> .wolf> 

<is? <> .goat> 

<is? <> .cabbage> 

<is? <> .farner» 
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<.aake t> 

;"exi> .sake with t" ]> 

;"if they are all safely on the other 

side of the river return t" 

<cond 

[<current? [looked-at 

• wolf 
.goat 
.cabbage 
.f araer ]> 

<.aake <» 

;"exit .make with <>"]> 

; w if we have already looked at this situation 

return <> which is false" 

<assert [looked—at .wolf .goat .cabbage .faricr]^ 

<or 

second 

[<is? .faraer .goat> 

♦ ••if the faraer is on the sane side 

as the goat, 

then he can carry the goat with 
hia to the other side" 

<goal [froa 

. wolf 

<not? .goat> 

.cabbage 

Cnot? .faraer> 1> ]> 

&<goal [froa 

• wolf 
.goat 

.catbage 

<not? .faraer>]> 

second 

r<is? .faraer .wolf> 

;"siailarly if the faraer is on the saae side 

as the wolf" 

<goal [froa 

<not? .wolf> 

. goat 
.cabbage 

<not? .faraer>J>]> 

&<cond 

[<is? .faraer .cahtage> 

<goal [froa 

.wolf 
• goat 

<not? .cabbage> 

<not? . faraer> ]> ]» 

;*the function OR tries the 

possibilities in order»> 
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<assert <define safety-check <consequent safety-check 

[wolf goat cabbage farmer] 

[safe ?wolf ?gcat ?cabbage Tfarmer] 

<cond 

[<or? 

<and? 

<is? .wolf <not? .faraer» 

<is? .wolf .goat>> 

<and? 

<is? .goat <not? . faraer» 

<is? .goat .caJ3bage>» 

;"the situation is not safe if either 

the wolf is on the opposite side 
from the farmer 

but on the sane side as the goat or 
the goat is on the opposite side from the 
farner bat on the same side as the cabbage" 
<fail <> ,safety-check> ]»» 

The protocol of the solution is: 


<goal [from t t t t]> 

<goal [from t <> t <>]> goat 

<goal [fron t t t t ]> goat 
<goal [from t <> t t]> himself 

<goal [from t <> t <>]> himself 
<goal [from <> <> t <>]> wolf 
<goal [from <> t t t]> goat 

<goal [from <> <> t <>]> goat 
<goal [from <> t t <>]> himself 

<goal [from <> t t t]> himself 
<goal [from t t t t]> wolf 
<goal [from <> t <> <>]> cabbage 

<goal [from <> t <> t]> himself 

<goal [from <> <> <> <>]> goat 

Note that there are several things wrong with the above procedure. 

For one thing the problem solver should work forwards and backwards 
simultaneously trying to find necessary conditions for a solution as 
well as sufficient condtions. The procedure is not very smart in the 
way that it goes about looking for a solution. These ills can be 
cured in various ways. The reader might find it instructive to 
consider some of the possibilities. 
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5.5.2 PLANNEB Does only Depth First Search 


PLAHNEB runs under a backtrack control structure. Because of 
the control structure the execution tree of a process locks like a 
depth first investigation. However, by creating more processes the 
growth of the set of execution trees can be quite arbitrary. As an 
example we can convert the above solution to the farmer, goat, 
cabbage, and wolf problew to breadth first investigation by evaluating 
the arguments to OB in parallel instead of sequentially in the theorem 

HAKE-HOVE. 

5.5.3 Use of Failure Implies Inefficient Search 

The failure primitive in PLAHNEB is a method of transferring 
control. The concept does not have any necessary relation to program 
errors such as dividing by zero. Often a proof by contradiction is 
completed by generating a failure back to an label function with a 
message like ** happiness** when the contradiction is detected. The 
message is caught when it propagates back to the point where the proof 
by contradiction was set up. The effect of the failure is to get rid 
of all the garbage that is generated in the proof by contradiction. 

In a similar vein the failure mechanism is often used as a summarizing 
mechanism. At certain points along the computation, certain 
conclusions are derived from the process of investigation. These 
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conclusions can be lifted cut of the details that were used to derive 

thea by failing back with values which suaaarize ahat has been 
learned. Then the coaputation can continue with a cleaner slate. 

For exaaple in a chess prograa, exploration of the possible aoves 
night reveal that our gueen is pinned against our king threatening the 
loss of the queen. Inforaation to that effect would be passed back 
with the failure. 

5.5.4 PLANNEE Does Only Hhat It Is Told 

In a strict sense PLAHNEB does only what it is told to do. 
There is no randoa eleaent or independent consciousness built into the 
priaitives. However, because ofthegoal oriented nature of the 
foraalisa it is very difficult to predict what a large body of PLAHNEB 
theorens will do. In fact one of the aore obnoxious things that can 
happen is that soae theoreas find a nonobvious way to accoaplish a 
trivial goal. Usually this happens because there is a bug in the code 
for the obvious way to achieve the goal. 
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6. Here on PLANNER 


6.1 PLANNER EXAMPLES 

6.1.1 London's Bridge 

Host of the tine we decide which statements we want to erase 

on the basis of the jnstifications of the statements. If we erase 

statement a, and statement b depends on statement a because a is part 

of the justification of b, then we probably want to erase statement b. 

Sometimes a decision is made on the basis of other criteria. For 

example suppose that we carefully remove the bottom brick from a 

column of bricks. Be shall suppose that each brick is of unit length. 

The statement [at (brick) (place) ]height|] will be defined to mean 

that brick (brick) is at place (place) at the height (height). 

Suppose that have the following theorems: 

[at brick1 here 0} 

[at brick2 here 1j 

[at brick3 here 2] 

<define london's-bridge 
<erasing 

C 

[<brick> brick other-brick] 

[<place> place] 

[<integer> height]] 

[at _brick _place ^height] 

<erase 
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[at 

..other-brick 
• place 

<add1 .height>] 

[ -»use-> <?>]> 

;"erase the fact that there is another brick 

in the place above brick" 

<assert 

[at .other-brick .place .height1> 

;"assert that it is where 

brick used to be"» 


Thus after <erase [at brickl here 0]> we will have [at brick2 here 0] 

and [at brick3 here 1], The upper bricks in the tower have all fallen 

down one level. The above exaaple coaes froa a suggestion aade by S. 
Pa pert. 


6.1.2 Analogies 



6.1.2.1 Siaple Analogies 

Our next example illustrates the usefulness of the pattern 

directed deductive systea that P1ABHBB uses coapared with the 

quantificational calculus of order oaega. Be are interested in siaple 

analogies such as those explored by Toa Evans. Given that object al 

has some rexation to object a2 and that object cl has the saae 

relation to object c2, the problea is to deduce that al is analogous 

to cl. He use the predicate test-analogons within the theorea pair to 

record that we think two objects night be analogous and that we would 

like to check it out. Suppose that we give P1ABBEB the following 
theoreas: 
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<define 


<define 


[inside al a2] 

[inside cl c2 ] 

[a-object al ] 

[a-object a2 ] 

[c-object cl] 

[c-object c2] 

pair <consequent pair 

[<object> a c] 

[<functor> predicate] 

[{?} argsal argsa2 argscl argsc2]] 

[analogous ?a ?c ?predicate] 

<unique> 

;"the current goal must be unique” 

<cond 

[<current? [test-analogous ?a ?c]> 

;”if a and c are test-analogous then 

we are done” 

C.pair done> 

;"exit .pair with done”]> 

<current [a—object ?a]> 

<current [c-object ?c]> 

;”find an a-object and a c-object” 

<assert [test-analogous .a .c ?predicate]> 
Ccurrent [?predicate !.argsal .a !_argsa2]> 
<current [.predicate !_argscl .c !_argsc2]> 
;”find a predicate in which both a and 

c are arguments” 

<cond 

[<is? <non []> .argsa1> 

<goal [corresponding-analogous 

.argsa1 
•argscl 

. predicate ]> ]> 

<cond 

[<is? <non []> .argsa2> 

<gcal [corresponding-analogous 

•argsa2 


•predicate]>]> 

;"show that the other arguments are analogous” 
<assert [analogous .a .c .predicate]>» 


chop-of£-another <consequent 

[<object> a b] 

[ J?) aa bb ] 
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[<functor <?> <?» predicate]] 

[corresponding-analogous [?a ??aa} [?c ??cc] ?predicate ] 

<cond 

[<current? [test-analogous ?a ?c ?predicatej> 

;"if a and c are currently test-analogous then 

we only have to look at 
the rest of the eleaents” ] 

[-•"else" 

Ccurrent [analogous ?a ?c ?predicate ]> ]> 

<ccnd 

[<is? <non []> ,aa> 

<current [corresponding-analogous 

?aa 


?cc 

?predicate ]> ]»> 


Thus if we ask PLANNEE to evaluate <goal [analogous al ?x inside]> 
then x will be bound to cl in accordance with the following protocol: 


<goal [analogous al ?x inside]> 

enter pair 

a gets the value al 
c gets the value ?x 
predicate gets the value inside 
<unigue> 

<current [test-analogous at ?c inside]> 
FAIL 

<current [a-object a1]> 

<current [c-cbject ?c]> 

node 1 

c gets the value c2 
x gets the value c2 

<tenporary [test-analogous al c2 insidej> 

<current [inside al a2]> 

Ccurrent [inside cl c2]> 

<goal [corresponding-analogous [a2] [] inside1> 

enter chop-off-another 
FAIL 

FAIL 

node 1; note that this node appears above 

c gets the value cl 
x gets the value cl 

<tenporary [test-analogous al cl insideJ> 

<current [inside cl c2]> 

<goal [corresponding-analogous [a2] [c2] inside ]> 

enter chop-off-another 
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a gets the value a2 
c gets the value c2 

<current [test-analogous 

a2 

c2 

inside ]> 

Fill 

<current [analogous a2 c2]> 

enter pair 
a gets the value a2 
c gets the value c2 
<unique> 

<current [test-analogous 

a2 

c2 

inside]> 

FAIL 

<current [a-object a2]> 

<current [c-object c2]> 

Ctemporary [test-analogous a2 c2 inside ]> 
<current [inside al a2]> 

<current [inside cl c2 ]> 

<gcal [correspoinding-analogous 

[al] 

[cl] 

iaside ]> 

enter chop-off-another 

a gets the value al 

c gets the value cl 

<current [test-analogous al c1]> 

succeed 

In the process of carrying out the evaluation the folloving additional 
facts will be established: [analogous al cl inside] and [analogous a2 
c2 inside]. The reader night find it anusing to try to fornulate the 
above problem in the first order guantificational calculus. 


6.1. 2.2 Structural Analogies 


The process of finding analogous proofs and methods plays a 
very important role in theorem proving. For example the proofs of the 


i 
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unigueness of the identity eleaent and inverses in seai-groups are 
closely related. The definitions are: 

[equivalent [identity e3 [equal [* a e] [* e aj a]] 

[iaplies [identity e] [equivalent [inverse bl b] [egual £* bl b] [* b 
bl] e]]] If e and e* are identities, then ve have [egual e [* e e* ] 
e* ]. If al and al* are inverses of a, then ve have [equal al [* al* 
a al] al]. The general fora of the analogy is [egual v ^string v*] 
where .string algebraicly siaplifies to v and v*. In aany cases 
analogies are found by construction. That is the problea solver looks 
around for problems that might be solved with an analogous technique. 
In other words ve will have a aethod of solution in search of a 
problea that it can solve! Sow that we have found a technique for 
proving that various kinds of eleaeats are unique, let us look around 
for a similar problea to shich our technique applies. He find that 
zeros in seai-groups are defined as follows: 

[equivalent [zero z] [equal [* a z] £* z a] z ]] Supposing that z and 
z* are zeros we find that [equal z [* z z*] i'], Cne aa^or problea in 
the effective use of analogies in order to solve probleas is that it 
is very difficult to decide when and at what level of detail to try 
for an analogy. Another problea is that often the analogy holds only 
at a quite abstract level and it aust not be pushed too far. Consider 
the following two algorithas: 

<defiae nuaber-of-atoms 
[function [z] 

<cond 
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[<enpty? .x> 

0 ] 

[<is? !=atca . x> 

1 ] 

[-» M else" 

<♦ 

<nuaber-of-a to is <1 .x» 
<nuaber-of-atoas <rest . x»>]>]> 

<define list-of-atoas 
[function [x] 

<cond 

[<eapty? .x> 

111 

[<is? !=atca .x> 

[-*]] 

[-.«*else w 

<append 

<list-of-atoas <1 ,x» 
<list-of-atoas <rest ,x>»]>]> 


The functions nuaber-of-atoas and list-of-atoas are precisely 

analogous. In aost cases two functions will not be nearly so 
siailar. Very few of the ideas of one will be used in the other. 
Structural analogies aay also be constructed by procedural abstraction 
[see chapter 7]. Bledsoe has suggested that still another exaaple of 
analogous proofs is found in the Schwartz ineguality: 



<* <x 1> <y 1» 
<* <x 2> <y 2>» 


<expt <x 1> 2> 
<-. <x 2> 2» 

<-. <y 1> 2> 

<-» <y 2> 2»» 
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<nodccreasing 

<expt 


<* 


<sigaa 



1 

n 

<function 

[i] 

<expt <* <x .i> <y .i» 2»> 


<sigaa 


<sigaa 


1 

n 

<function 

[i] 

<expt <x . i> 2»> 

1 

n 

<function 

[i] 

<expt <y .i> 2»»> 


<nondecreasing 

<expt Cintegral <* x y» 2> 

<integral <expt £ 2» 
<integcal <-* g 2»» 


6.1.3 mathematical Induction 


He can foraulate the principle of aatheaatical induction for 
the integers in the following aay: 


<de£lne induction <conseguent [p] 

[for-all _p] 

Cteaprog [[a <arbitrary <integer»]] 

<goal i»<.p 0» 

<assert !*<.p .n>> 

<goal !*<.p !•<♦ .a 1»» 
<assert £ for-all .p]>» 
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If we are given the facts [* <♦ P 0> 0] and 


<clanse [x y] 

<♦ ?y <♦ ?x 1» 

<♦ <+ ?y ?x> 1>]> 

then we can establish 


£for-all <function [n] [ = <♦ 0 ?n> ?n]>]. 


The following theoren will do induction on s-expressions: 


<define expr-induction 
Consequent 

Cp3 

[for-all _p] 

<teaprog 

[[a <arbitary <aton»3] 
<goal !*<.p .a»> 

<tenprog 

C 

[car <arbitcary <expr»] 
[cdr <arbitrary <expr»33 
<assert t*<.p ,car» 

<assert !*<.p .cdr» 

<goal !*<.p !*<cons .car . cdr»» 
<assert [for-all .p]>» 


Be would like to try to do without existential quantifiers. Be can 

eliminate then in favor of Skoles functions in assertions and in favor 
of PLAMBS! identifiers in goals. The problen of finding proofs by 
induction is foraally identical to the problen of syntesizing programs 
out of "canned loops". The process of procedural abstraction [which 
is explained in chapter 7] has an analogue which is "induction 
abstraction" [finding proofs by induction fron exaaple proofs written 
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out in full without induction]. 


6.1.4 Descriptions 


6.1. 4.1 Structural Descriptions 


PLANNED can be used to find objects froa partial or schematic 
descriptions. The stateaent [perpendicular [line _a _b ] [line _c 
_d]] will be defined tc nean that the lines [line .a .b] and [line .c 
.d] are perpendicular. The HATCHLESS function <ASSIGNED? arg> tests 
to see if the identifier arg has a value. We shall adopt the 
convention that [glued a b] leans that bricks a and b are glued 
together and [orthogonal [line |a! lb|] [line |cl Id]]] leans that the 
lines between the centers of bricks ]a| and jb| is orthoganal to the 
line between the centers of bricks |c| and |d|. A three-corner is 
defined to be a group of three bricks joined together such that two of 
then are diagonal to each other. A three-corner is shown in figure 1. 
In other words the following is a description of a three-corner: 


<define find-three-corner 
<conseguent 

[£<brick> a t> c]] 

[three-corner ?a ?b ?c] 

<goal [glued ?a ?b]> 

<prog again [] 

<goal [glued 

e 

<all <non .b> ?c>]> 

<goal [orthogonal [line .a .b] [line .a .c]]> 
<cond 
[<cr? 

£<goal [glued 



A Three - Corner! 

[cube l3 Cglued I 23 

[cube 21 [glued 2 33 
[cube 33 



A STICK : 

[cube 43 Cglued 4 53 

Ccube 53 [glued 5 63 

[cube 63 Cglued 6 73 

[cube 73 



ANOTHER STICK*. 

[cube 83 [glued 8 93 
[cube 93 Cglued 9 103 
[cube 103 
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• d 

<all <non .b> <non ,c>>J> 
6<goal [glued .b <non .a>]> 

6<goal [glued .c <non .a>]>> 

<£ail <> again>]»» 


The description can be used in the obvious way to find three-corners. 

The statement [stick _a _b ] is defined to mean that .a and .b are end 
bricks of a line of bricks and [between _a _b _c] is defined to mean 
that brick .b is between bricks .a and .c. Examples of sticks are 
shown are shown in figure 1. 


<define find-stick 

<consequent 

[[<brick> a b] [!*fix n}] 

[stick ?a ?b _n] 

<current [brick ?a]> 

<current [brick ?bj> 

<goal [stick-segment .a .b <- .n 2>]> 
<assert [stick .a .b .n]>» 


<define find-stick-segment 
<conseguent find 

[[<brick> x y wj[!*fix n]] 

[stick-segment ?x ?y _n] 

<cond 

[<is? <neg> .n> 

<fail>] 

[6<goal [glued ?w ?x ]> 

<goal [orthogonal 

[line .x «w] 

[line .x ?y]]> 

<fail>] 

[6<goal [glued ?x ?y]> 

<cond 

[<and? 

<goal [glued ?w ?y]> 
<goal [orthogonal 

[line ,y .*] 
[line .y .x]]» 


<fail>]> 

<.find t> 

;«exit .find with t"3> 


<goal [glued ?w *x]> 
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<goal [between .x .w .y]> 

<goal 

[stick-segment .v .y <- .n 1>] 
[-»use-» find-stick-segment <?>']>» 


6.1.4.2 Constructing Examples of Descriptions 


Given a description of a structure [such as a stick] we would 
like to he able to derive a general method for building the structure. 
The problem of deriving such general construction methods from 
descriptions is very difficult. In this case we we can construct a 
stick of length n with ends x and y using the functions <GLUE facel 
face2> which glues the value of facel to the value of face2 and the 
function new-brick which produces a new brick. 


<define make-stick <consequent make 

([<brick> x y w] [!=fix a]] 
[make-stick _x _y _n] 

<cond 


[<is? <less 3> .a> 

<glue [bottom .x] [top .y]> 
<.make t> 

;"exit .make with t"]> 

<is _w <new-brick» 

<glue [bottom «x] [top .w]> 

<goal [make-stick _w _y <- n 1>]»> 


6.1.4.3 Descriptions of Scenes 


S. Papert has suggested that theorem proving techniques might 
be applied to the problem of analyzing 2-dimensional projections of 3 
dimensional bricks. In this section we will give a formal definition 
of the problem, kdolpbo Guzman has developed a program [called SEE] 






6.1 page 268 


which tries to solve such probleas. Many humans solve such problems 

by mentally constructiing a symbolic 3-dimensional scene which 
optically projects back to the given 2-dimensional input. Be define a 
brick to be a connected open opagce region of 3-space bounded by a 
finite number of planes such that if two planes intersect then they 
must be orthogonal. Furthermore, the complement of a brick is 
required to be connected. Thus bricks are allowed to have holes in 
them. k 3-dimensional scene is an arrangement of bricks such that no 
two of them intersect, k 2-dimensional scene is a collection of 
straight lines in a plane, k 2-dimensional projection is the optical 
projection of a 3-dimensional scene onto a plane, k statement p about 
3-dimensional scenes will be said to be valid for a2-dimension al 
scene r if for all 3-dimensicnal scenes t such that t projects to r it 
is the case that p is true for t. k two dimensional scene rO will be 
said to be ambiguous for a language 1 if it is the projection of two 

3-dimensional scenes tl and t2 such that there is a sentence pO in 1 

with pO true in tl and false in t2. There are a number of primitive 
predicates that should be included in a language for scene analysis: 

[parallel x y] means that x and y are parallel. 

[coplanar x y] means that x and r are coplanar. 

[normal planel directed-linesegment] means that the normal of 
planet is in the direction of the directed-linesegment. 

[restricted planel ptl pt2 pt3] means that the normal to 
planel is restricted to the angle ptl pt2 pt3. 

[sape-brick region1 region2] means that regionl and region2 
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are part of the saae brick. 

[adjacent region 1 region2] Beans that regicnl and region2 are 
regions of the sane brick that intersect at right angles. 

[convex region 1 region2] Beans that region 1 and region2 are 
regions of the sane brick that intersect at right angles to lake a 
convex body. 

[concave region 1 region2] Beans that regionl and region2 are 
regions of the saae brick that intersect at right angles to aake a 
concave body. 

[eleaent x y] aeans that x is an eleaent of y. 

[in-frcnfc-of brickl brick2] aeans that brickl is in front of 

brick2. 

[resting-on brickl brick2] aeans that brickl is resting on 

brick2. 

[on-top-of brickl brick2] aeans that brickl is on top of 

brick2. 

[subset x y] aeans that x is a subset of y^ 

[coordinates pointl coordl] aeans that pointl has 3- 
diaensional coordinates coordl. 

The folloving stateaents about exaaplel are valid as can be seen by 
considering shere the noraals of the planes aight lie and deducing 
consequences until contradictions are found. 

[noraax a idirection 7 13]] 

[noraal b [direction 12 13]] 

[convex a b] 






[convex a 
[convex b 
[noraal c 
[noraal d 
[noraal e 
[convex d 
[noraal £ 
[convex d 
[convex e 
[noraal h 
[noraal 9 
[convex 9 


c] 

C] 

[direction 
[direction 
[direction 

[direct ion 

f 3 
f 3 

[direction 
[direction 


10 13}] 
7 4J] 

2 4 ] } 

3 4]] 


16 18]] 
15 16]] 


The follovin 9 stateaent about exaaple 1 satisfiable: 


[ and 

[resting-on [brick a b c] [brick e £ d]] 
[resting-on [brick a b c] [brick g h]]j 

The £olloving stateaents about exaaple 2 are valid: 

( convex a c] 
convex a b] 

[ convex be] 

[noraal a [direction 12 14]] 

[noraal c [direction 3 14]] 

£ convex 9 h] 

[noraal 9 [direction 5 6 ]] 

[noraal h [direction 8 6 ]] 

[not [adjacent c d]] 

[not [adjacent b d]] 

[convex d e] 

[convex e £] 

[convex d £] 

[noraal e [direction 4 13]] 

[noraal 4 [direction 9 13]] 

[noraal £ [direction 11 13]] 


The following stateaent about exaaple 2 is satisfiable 


[ and 

[saae-region c g] 
[saae-region b h] 

[ saae-brick a b c 9 h ] ] 
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The three diaensional coordinates of points are obtained by 

using aore than one caaera to view the scene or using a focus nap. In 
the case where we have coordinates as a prinitive predicate, the 
definition of a projection of a 3-diaensional scene aust be aodified 
to include the 3-dinensional coordinates of all the projected 
vertices. In the case where we have the three diaensional co¬ 
ordinates of the projected vertices, we can deduce that two planes are 
part of the sane brick if they intersect at an acute right angle. 

Since the. object that is being viewed sight be so far away that 
accurate coordinates cannot be obtained, a deductive systea should be 
developed which does not use coordinates, it the very ainiaua a hard 
core deductive systea for the analysis of 2-diaensional projections 
should be consistent and every valid stateaent should be proveabxe. 
That is every theorea of the systea snould be satisfiable [there is at 
least one interpretation that satisfies the theoreaj. Interest in 
questions of satisfiability cones froa the fact that soae 
interpretations are far aore likely than others in the real world. 
Statwaents that are to be tested for satisfiability aust be aade as 
strong as possible in order to provide a aeaningful cest. Although 
the linking rules are aatheaatically very elegant, in their present 
fora they do not adeguately represent the seaantics of the optical 
projection rules. The value of the pregraa by Guxaan is that it 
provides conjectures about which regions are satisfiable in the 
relation sane-brick. However, the prograa suffers because it does not 
have any explicit knowledge of optics. He would advocate an approach 
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that aakes greater use of deduction to test the validity or 

satisfiability of a sentence. Questions of satisfiability and 
validity of sentences with respect to any given projection are 
decidable since the theory of real closed fields is decidable. 
Efficient algoritheas should be developed to test whether a given 
sentence is valid or satisfiable in a projection. 


6.1.4.4 Power Set of Intersection of Two Sets Is the Intersection of 
Their Power Sets 


The following example was proposed by W. Bledsoe. Prove that 
the power set of the intersection of two sets is the intersection of 
their power sets. He shall use cap as a synonym for intersection. 


<define extensionality-conse <conseguent [[<set> x y]1 

( = ?x ?y j 

<goal [subset ?x ?y]> 

<goal [subset ?y ?x]> 

<assert [ = . x ,y]>» 

<define eleaent-power-conse Consequent [[<set> x all 

[element ?x [power ?a]] JJ 

<goal [subset ?x ?aj> 

<assert [element .x [power .a]]»> 

<define elaaent-power-ant Antecedent [[<set> x all 

[eleaent ?x [power ?aj] 

<assert [subset ?x ?a]»> 

<define subset-cap-ccnse Consequent [[<set> a b ell 

[subset ?c [cap ?a ?b]] JJ 

<goal [subset ?c ?a]> 

<goal [subset ?c ?b]> 

<assert [subset .c [cap .a .b]]>» 

<define subset-cap-ant <antecedent [[<set> a b c]l 

[subset _c [cap _a _b]] 
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<assert [subset .c .a]> 

<assert [subset .c .b]»> 

<define subset-cap-conse Cconsequent [[<set> a b c]] 

[subset 7c [cap ?a ?b]] 

<goal [subset ?c ?a]> 

<goai [subset ?c ?b]> 

<assert [subset .c [cap .a .b]]>» 

<define element-cap-ant <aotecedent [x [<set> a b]] 

[element _x [cap _a _b]] 

<assert [element .x .a]> 

<assert [eleaeot .x ,b]>» 


<de£ine eleaent-cap-coose <conseguent [x [<set> a b]] 

[eleaeot ?x [cap ?a ?b]] 

<goal [eleaeot ?x ?a ]> 

<goal [eleaeot ?a ?b ]> 

<assert [eleaeot ?x [cap ?a ?b]]»> 

<define subset-conse <coosegueot [[<set> a b]] 

[subset .a ?b] 

<temprog”[x <arbitrary <?»] 

<assert [eleaeot .x . a]> 

<goal [eleaeot .x .b]» 

<assert [subset .a «b]>» 


Be cao now set up ouc goal to prove the theorea: 


<goal [ = 

[cap [power al] [power a2]] 

[power [cap al a2]]]> 

The goal will produce the followiog protocol: 

enter extensionality-conse 

x becoaes [cap [power al] [power a2]] 

y becoases [power [cap al a2]] 

<goal [subset [cap [power al] [power a2]][power [cap al a2]]]> 
enter subset-conse 

a becoaes [cap [power al] [power a2]] 
b becoaes [power [cap al a2]] 
x becoaes gl 
<assert 

[eleaeot 

gi 

[cap [power al ] [power a2]]]> 
enter eleaent-cap-ant 

x becoaes gl 
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a beccaes [power al] 
b becomes [power a2 ] 

<assert [element gl [power at]]> 
enter element-power-ant 

<assert [subset gl a1]> 
<assert [element gl [power a2]]> 
enter eleaent-power-ant 

<assert [subset gl a2 ]> 
<goal [element gl [power [cap al a2]]]> 
enter elenent-power-conse 

x becoaes gl 
a becoaes [cap al a2 ] 

<goal [subset gl [cap al a2]]> 
enter subset-cap-conse 

c becomes gl 
a becomes al 
b becomes a2 
<goal [subset gl a1]> 
<goal [subset gl a2]> 
<assert 


<assert 


[subset 

gi 

[cap al a2]]> 


[element 

gi 

[power [cap ai a2]]]> 

<assert 

[subset 

[cap [power al] [power a2]] 
[power [cap al a2]]]> 

<goal 

[subset 

[power [cap al a2]] 

[cap [power al] [power a2]]J> 
enter subset-conse 

a becoaes [power [cap al a2]] 
b becoaes [cap [power al] [power a2]] 
x becoaes g2 

<assert [eleaent g2 [power [cap al a2]]]> 
enter eleaent-power-ant 

x becoaes g2 
a becoaes [cap al a2] 

<assert [subset g2 [cap at a2]]> 
enter subset-cap-ant 

x becoaes g2 
a becoaes al 
b becoaes a2 
<assert [subset g2 al]> 
<assert [subset q2 a2]> 
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<goal 

[eleaent 

92 

[cap [power al] [power a2]]]> 
enter eleaent-cap-conse 

x becoaes g2 
a becoaes [power al] 
b becoaes [power a2 ] 

<goal [eleaent g2 [power a1]]> 
enter eleaent-power-conse 

x becoaes g2 
a becoaes al 
<goal [subset g2 a1]> 

<goal [eleaent g2 [power a2]]> 
enter eleaent-power-conse 

x becoaes g2 
a becoaes al 
<goal [subset g2a1]> 

<assert 

[eleaent 

g2 

[cap [power al] [power a2]]]> 

<assert 

[ subset 

[power [cap al a2]] 

[cap [power al] [power a2]]]> 

<assert 

[= 

[power [cap al a2]] 

[cap [power al] [power a2]]]> 


6.1.5 Seaantics of Natural language 

Although probleas for P1ANMEB are typically phrased in a 
perfectly feraal, precise, unaabiguous syntax, we will usually not 
find the seaantics as well defined. If we say [[very happy] John] 
instead of "John is wery happy." we will not thereby have aade the 
concept of happiness any less nebulous for the aachine. Nevertheless 
it is convenient for a problea solver to have such concepts although 
they are not rigorously defined. Probleas of seaantic aabignity and 
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clarificatcn can require arbitrary amounts of computation in order to 

be adequately resolved. For example consider the following simple 
example of how semantic ambiguities can be eliminated with the aid of 
"real-world” Knowledge: 

<assert [ is—smaller-than hand [pig pen]]> 

<assert 

<define example-of-bar-hillel 
<antecedent [[<object> x y]] 

[in _x _y ] 

<cond 

[<is? pen .x> 

<goal [is-smaller-than ?y [pig pen] ]> 

<assert [in [fountain pen] *y]>]»» 

Now if we assert [in pen hand], PLANNEB will conclude that [in 

[fountain pen] hand] is true since a hand is smaller than a pig pen. 
One of the important difficulties that have plagued most of the 
programs that have been written to answer questions in English is that 
they are trying to solve two very hard problems at the sane time. 

First they must make sense of English syntax and second they need a 
powerful problen solving capability to answer the question once they 
have "understood” it. Ambiguous cases should be resolved on the basis 
of deduction and not on the basis of seme linking scheme such as 
"semantic memory". As it stands PLANNEB provides sophisticated 
mechanisms for solving problems in formal languages. A program could 
be written [perhaps in PLANNEB?] to translate English into PLANNER 
theorems for problem solving. Conversely we could try to translate 
PLANNEB theorems into simple natural language. Surprisingly 
translation into natural language can be very awkward because natural 
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language lacks many of the descriptive and procedural primitives of 
PLAHNEB. 


6.1.6 The Pons Asinorux 


We would like to show how the "bewilderingly simple" proof of 
the pons asinorun [i. e., base angles of an isoscles triangle are 
equal] can be done very simply in PLANHEB. The following notation 
will be used: 


[length JplJ Ip2|] for the length from point |p1| to ]p2| 

[angle ]x] |y| ]z|] for the angle JX] |y| |z| which has the 
point |yj at its vertex 

Pour PLANMEB theoreas are used. They are procedural analogues of 
axions in plane Euclidean geometry. 


<define side-angle-side 

<conseguent [xl x2 x3 yl y2 y3 ] 

[congruent [7x1 7x2 7x3] [?y1 7y2 ?y3]] 

<unigue> 

<goal [= [length 7x1 7x2] [leugth 7y1 7y2]]> 

<goal [= [angle 7x1 7x2 7x3] [angle 7y1 7y2 ?y3]]> 
<goal [* [length 7x2 7x3] [length 7y2 7y3j]>» 

<define equal-angle 

<conseguent [pi p2 p3 w] 

[= [angle 7p1 7p2 7p3] ?w] 

<unique> 

<goal [= [angle 7p3 7p2 7p1 ] ?w]>>> 


<define egual 

<consequent [x y] 

£~ ?y3 

<unique> 

<or 

<aatch ?x ?y> 

<goal [ = ?y ?x]»» 
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<defi.ce angles-by-congruence 

Consequent [pi p2 p3 gl q2 g3] 

£ = [angle ?p1 ?p2 ?p3] [angle 2g1 ?q2 ?g3]] 

<unique> 

<goal 

[congruent 

[?pt ?p2 ?p3] 

[?g1 ?q2 ?q3]]»> 

Suppose that ve have an isosceles triangle ABC with the length of AB 
equal to the length of AC. Be can input this as: 


<assert [* [length A B] [length A C]J> 

The goal is to prove that angle ABC is equal to angle ACB: 


<goal [= [angle ABC] [angle A C B]]> 

One protocol for establishing the goal is: 
eater angle-by-coagruence 

pi becones A 

p2 becones B 

p3 becones C 

ql becones A 

q2 becones C 

q3 becones B 

<goal [congruent [A B C] [A C B]]> 
enter side-angle-side 
pi becones A 
p2 becones B 
p3 becones C 
ql becones A 
q2 becones C 
q3 becones B 

<goal [* [length A B] [leagth A C1]> is easy since it is la 
the data base 

<goal [« [angle B A C] [angle C A B]]> 
enter equal-angle 
pi becones B 
p2 becones A 
p3 becones C 
« becones [angle CAB] 

<goal [= [angle CAB] [angle C A B]]> 
enter equal 

x becones [angle CAB] 
j becones [angle CAB] 
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<goal [- [length A C] [length A B]]> 
enter egaal 

x becoaes [length AC] 
y becoaes [length A B] 

<goal [* [length A B] [length A C]]> succeeds by 
looking in the data base 


Ira Goldstein has iapleaented a Gerlernter-like geoaetry 


theorem prover. 
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6.2 Current Problems and Future Work 


PLANNEE would benefit greatly from an efficient parallel 
processing capability. The system would run faster if it could work 
on its goals in parallel. Quite often a goal will fail alter a short 
computation along its path. The use of parallelism would enable us to 
get many goals to fail so that we could adopt more of a progressive 
refinement strategy. He would like to carry out computations to try 
to reject a proposed subgoal at the same time that we are trying to 
satisfy it. Hany computations can be carried out much faster in 
parallel than in serial. For example we can determine whether a graph 
with n nodes is connected or not in a time proportional to <* <log n> 
<log n». It has been known for a long time that lisp computations 
using parallel evaluation of arguments are determinate if the 
functions rplaca, rplacd, and setg are prohibited. He could impose a 
similar set of restrictions on PLANNEB. Another approach is to 
introduce explicit parallelism into the control structure. He have 
”l<" and ">" delimit parallel calls for elements and "|{« and *}« 
delimit parallel calls for segements. A parallel function call sill 
act as a fork in which one process is created to do the function call 
aind the other proceeds with normal order evaluation. For example in 
<* |<* 3 4> <♦ 7 8>> we could compute 3*4 in parallel with 7+8. The 
copy function could be sped up by a factor proportional to the number 
of processors: 


I 
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<de£ine copy [function [x] 

Ccond 

[<is? <acnadic> «x> 

.x ] 

[-."else" 

[l<copy <1 .x» (copy <rest .x>}]]>]> 

However, we would still have problems communicating between the 

branches of the computation proceeding in parallel. Partly this a 
problea of sharing an indexed global data base bet wen parallel 
processes. He would need the standard loch and unlock priaitives and 
unliaited use of assignment in order to keep the computations 
synchronized. But if we allowed the use of lock andunlockand 
unliaited use of assignment, the programs might become indeterminate. 
One of the most important properties that can be proved about a 
program is that it is determinate. 

PLANNEB logic is a kind of hybrid between the classical logics 
[such as the quantificational calculus and intuitionistic logic], and 
the recursive functions [as represented by the lambda calculus and 
Post productions]. The semantics of PLANHER logic is most naturally 
defined dynamically by the properties of procedures. The semantics of 
the quantificational calculus can be defined by set theoretic models 
of possible worlds. The logic of the guantificational calculus is 
COHSEBVATIYE in the sense that if a sentence S follows from a set of 
sentences H then S will follow from any superset of 8. Do to its 
ability to have conditional expressions that test the state of the 
world, P1AHMER logic is HOT conservative. This causes consternation 




6.2 page 283 


among classical logicians because many elegant theorems for classical 

logic do not hold for PLANHEB logic. The restriction of having to be 
conservative is quite severe in problem solving. Suppose that there 
are three cubes A, B, and C sitting on a table. Suppose that it is 
desired to build a tower two cubes high at place E. The plan 
constructed might be to pick up A, set it down at P, and then place B 
on top of it. If in the process of constructing the plan we deduced 
that cube A was glued to the table with liguid iron, we would want to 
change our plan to use cubes B and C to make the tower. But by the 
conservative properties of ordinary logic the original plan must 
remain valid. The only way around this would appear to be introduce 
some special kind of internal state into the deductive machinery of 
the guantificational calculus. Recommendations are another source of 
nonconservative behavior in PLAHNEB. For example we might not allow 
Zorn's Lemma to be used more than once in a proof. Both PLANNEB logic 
and guantificational logic are COMPACT in the sense that a computation 
{proof] depends on only a finite number of expressions. In comparison 
with the guantificational calculus PLANHEB would appear to be more 
powerful in the following areas: 

control structure 
pattern matching 
erasure 

local states of world 

There are interesting parallels between theorem proving and 
algebraic manipulation. The two fields face similar problems on the 
issues of simplification, equivalence of expressions, intermediate 
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expression bulge, and man-machine interaction. The parallel extends 

to tne trade off between domain dependent knowledge and efficiency. 

In any particular case, the theorems need not allow PLANNER to lapse 
into its default conditions. It will sometimes happen that the 
heuristics for a problem are very good and that the proof proceeds 
smoothly until almost the very end. Then the progam gets stuck and 
lapses into default conditions to try to push through the proof. On 
the other hand the program might grope for a while trying to get 
started and then latch onto a theorem that knows how to polish off the 
problem in a lengthy but fool proof computation. PLANNER is designed 
for use where one has great number of interrelated procedures 
[theorems] that might be of use in solving some problem along with a 
general plan for the solution of the problem. The language helps to 
select procedures to refine the plan and to sequence through these 
procedures in a flexible way in case everything does not go exactly 
according to the plan. The fact that PLANNEE is phrased in the fora 
of a language forces us to think more systematically about the 
primitives needed for problem solving. Be do not believe that 
computers will be able to prove deep mathematical theorems without the 
use of a powerful control structure. Nor do we believe that computers 
can solve difficult problems where their domain dependent knowledge is 
limited to finite-state difference tables of connections between goals 
and methods. Difference tables can be trivially simulated by 
conditional expressions in PLA1IEB. 
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Difficult problems for PLAHHEB 


Be would be grateful to any reader who could suggest types of problems 
which aight be difficult to encoapass naturally within the present 
foraalisa. PLANHEB is intended to be a good language for the 
creation and description of problea solving strategies. Currently it 
operates within the restriction of generalized stack discipline. By 
relaxing this restriction we could aake the language completely 
restartable at the considerable cost in efficiency of having to 
garbage collect the stack. 

Speed: PLINNEB runs best on a fast general purpose computer. 

However two special kinds of hardware would be useful. Alan Kay has 
pointed out that special hash code hardware could make the functions 
GET and POT as fast for nodes as indexing hardware does for vectors. 
Second if we had a load thru aask instruction, then we could speed up 
monitoring. The instruction would interrupt if the appropriate 
monitor bits were on. Both of the above kinds of instructions should 
probably be micro~coded. 

flemory: There is never enough fast random access storage. 
Furthermore the eighteen bit address space of the PDP-10 is 
inadequate. Be need a bigger address space for the following 


purposes: 
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Garbage collection 

Breathing space between data spaces [especially 

stacks ] 

Backtracking 

Dynamic linking 

Exploding definitions: We cannot afford to replace every tern 
by its definition in trying tc prove theorens. However, in the proof 
of almost every theorem it is necessary to replace some terms by their 
definitions. Domain dependent methods must be developed to make the 
decision in each case. 

Creating PLAHNEB theorems: We need to determine when it is 
desireable to construct PLANHEB theorems as opposed to dynamically 
linking them together at ran time. At the present we have only a few 
examples of nontrivial constructed theorems, we can generate some 
from the functional abstraction of protocols and from attempts to 
construct schematic proofs of theorems, others are generated as the 
answers to simple problems. For example if we ask the computer how it 
would put all the small green and yellow bricks in the red box, then 
it might answer: 


<for [f<face> facel face2] [<brick> brick]! 

[[-."current" [ small-brick J _brick]] ] 

<current [face _face1 .brick ]> "* 

<current [color .face! green ]> 

Ccurrent [face _face2 .brick]> 

<current [color~.face2 yellow]> 

<pick-up .bric k> 

<carry-to [above [re$ box]]> 

<drop>> 
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Terry Hinograd has developed a program to translate English into 

PLANNEB theorems. An interesting expreriment that could be attempted 
would be to modify a chess porgram so that it would return a PLANNER 
program as well as the symbolic description of a position. The idea 
is that the PLANNER program would represent the plan of action that 
would be taken in case of the various moves that the opponent might 
take. Hillias Hennenan has investigated some of the possibilites for 
doing planning in king and pawn end games. The problem seems to be 
very difficult but not impossible given the present state of the art. 

Arbitrary Constraints: Using procedures as a semantic base 
requires us to solve the problem of making procedural formalisms more 
goal-oriented. The quantificational calculus is very goal oriented 
but suffers growing pains trying to introduce procedural knowledge. 

Manipulation of PLANNEB theorems: PLANNER provides a flexible 
computational base for manipulating theorems that can be put in 
disjunctive normal form. He need to deepen our understanding so that 
we can carry out similar manipulations on PLANNEB theorems with the 
sane facility. 

Progressive refinement: He need to make mere use of the style 
of reasoning in which we construct a plan tor the solution of a 
problem from necessary conditions that the solution mast have, attempt 
to execute the plan, find out why it does not work, and then try 
again. The style is often used in chess where very nuch the ^ane 
game tree is gone over several tines; each tine with a deeper 
understanding of what factors are relevant to the solution. 
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Garbage collection of assertions: Stateaents which have been 

asserted should go away autonatically when they can no longer be of 
use. unfortunately, because of some logical probleas and becuause of 
the retrieval systea of PL&HHEfi, we have difficulty in achieving 
coapletely ante vatic garbage collection. The erase priaitive of the 
language provides one way to get rid of unwanted stateaents. If the 
asserted stateaent appears in the local state of sope process instead 
of in the global data base then it will disappear autoaatically. 

Simultaneous goals: Be often find that we need to satisfy 
several goals simultaneously, ie usually try to accoaplish this by 
choosing one of the goals to try to achieve first. However, when 
working on the goal, we should keep in Bind the other constraints that 
the goal Bust satisfy. One solution is to pass the goal to be worked 
on as a list whose first eleaent is the goal and whose succeeding 
elements are the other goals which aust be simultaneously satisfied. 

Honconstructive proofs: The aost natural way to do a proof by 
contradiction is to try to calculate in advance the stateaent which 
ultiaately will produce the contradiction. The aethod is to find a 
stateaent s such that S is provable and [not S] is provable. Bore 
precisely, we coapute a stateaent S, aake S a goal, and then aake [not 
S] a goal. Bob Boyer has pointed out that in aatheaatics if the goal 
is tc prove s, then if at any point in the proof the aain goal reduces 
to the subgoal to prove [not s}, then a proof by contradiction can be 
coapleted. 

Bodels of Doaains: Suppose that B is aodel for the set of 
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hypotheses H with conseguent c. Using constructive logic a subgoal s 

of the goal C would be rejected if it could be shown that it was 
unsatisfiable by N. Often rejections are aade on the basis of a model. 
For example in the intuitive model of Zermelo-Fraenkel set theory all 
the descending element chains are finite and terminate in the null 
set. Furthermore every set has an ordinal rank. Thus the ordinals 
form the back bone of the set theory. The intuitive meaning of [♦ A 
B] [where A and B are ordinals] is the concatenation of A with B. The 
intuitive meaning of [* A B] is the concatenation of A with itself B 
times. If two ordinals have the sane order type then they are equal. 
Thus intuitively we would expect that [= [+ 1 omega] omega] is true. 
Every well developed mathematical domain is built around a complex of 
intuitive models and simple examples and procedures. Axiom sets are 
constructed to attempt to rigorously capture and delineate various 
parts of the complex. One of the most important criteria for judging 
the importance of a theorem is the extent to which it sheds light on 
the complex of the domain. These complexes must be mechanized. Me 
conclude that it is unlikely that deep mathematical theorems can be 
proved solely from axioms and definitions by a uniform proof 
procedure. A uniform proof procedure based on model resolution does 
not provide the means for mechanizing the complex of a dcmain. Model 
resolution is a strategy for deciding which clauses to resolve. There 
is a great deal more tc mechanizing the complex of a domain than 
simply pruning proof trees. Furthermore, clauses are often false in a 
model even though they ate irrelevant to the proof that is being 
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sought. One way that is often used to try to find a counterexample 

to a false stateaent about ordinals is to atteapt to construct the 
counterexaaple froa well known ordinals. Soae well known ordinals are 
1, 2 , 3, oaega, the least uncountable ordinal , etc. Thus in seeking a 
counter exaaple to the statement that there are only finitely many 
Unit ordinals less than a given ordinal we need go no further than [* 
oaega omega]. 
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7. Models of Procedares and the Teaching of Procedures 


7.1 Models of Procedares 

7.1.1 Models of Expressions: Intentions in IHTBHDEB 

k problen solver needs to have sone way to knew the properties 
of the procedares which it ases to solve problens. It can use the 
knowledge which it has as a partial nodel of itself. In order to be 
able to nodel procedures, it needs: 

1: a way to express properties cf procedares. 

2: k way to establish that the properties do in fact hold for 
the procedares. 

IMTEHDES is a goal-oriented foraalisn for expressiong aodels 
of procedares. The nodels are expressed in terns of intentions of 
what the procedure should acconplish. The prinitives of IBTEVDEfi are 
concerned with expressing intentions in procedural terns. Thus the 
intentions ace capable of thenselves having intentions. IMTEHOSP 
nechanizes the knowledge needed to do execution induction on 
procedares. It calls on P1AHIEB to satisfy goals and uses PLAHKEB 
theorens to hold the substantive knowledge (such as facts about 
integers) which are needed to prove properties of procedures. 
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INTENDER has three oain uses for PLANNER: 

1: It enables PLANNER to verify that its procedures 

do what is intended. 

2: Host knowledge io PLANNER is embedded in 

procedures. INTENDER helps PLANNER understand these 

procedures and thus to have some knowledge of its own 

problem solving behaviour. 

3: IN TENDER enables PLANNER to verify that its plans 

(procedures) are valid relative to its procedural 

model of the world. 

He shall express the properties of an expression x by the 
following function. 

CINTENT 

[-declarations- ] ]predecessor| |xj |function| - 
successors-> is true if Jpredecessor| evaluates to true, the function 
applied to the value of jxj is true, and the -successors- all evaluate 
to true. The value of the function intent is the value of ]x|. The 
function intent is used to state a model for an expression x. As might 
be expected the models are stated in PLANNER. The intentions are 
established by INTENDER which is the language in which intentions are 
stated. The proof is by induction on the activations of the 
procedure. Thus for the control structure of LISP, the proof is by 
recursion induction. To avoid confusion we shall write the intention 
variables in upper case. Also we shall use !* to suppress 
invocations. Thus <♦ 2 3> evaluates to the number 5 while !*<♦ 2 3> 
evaluates to <* 2 3>. For example the intentions in the prog below 
are all true. 
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<prog foo [[a 1] [b 2]] 

!;<intent [] <goal !•«= 1 .a>» 

;"Xes the identifier ae was 

indeed initialized) to 1. Will) wonders sever cease? 1 * 
!;<intent [ ] <goal ! • <= „b !•<♦ .a 1>»» 

! ;<intent [ ] 

<goal !*<= .b 2» 

<_ ib <♦ .b 1» 

<function [X] <goal !•<= .X 3»» 

<goal I *<=.b 3>» 

»"®e have just verified that an assignment statement 

can change the value of the identifier b from 2 to 3" 
<.foo .b> 

; w exit .foo with .b"> 

The following protocol for XSTENDEH verifies that the 
intentions in the above program do in fact hold. We shall use the 
notation Jidentifier(_|n) for the In 1th value of (identifier) and 
(idenifierl for the initial value. 


<assert ! *<= 1 a_» 

<assert !•<* 2 b~>> 

<goal !'<= 1 a » 

<goal !•<= b !•<♦ a 1»> 

<goal !•■<* 2 b_» 

<assert !•<= b 1 <♦ b 1»> 

<goal !«<* <♦ b_ 1> 3>> 

<goal !*<= b.1 3» 

The essential idea for intentions comes from the break 
function introduced into LISP by w. Martin. An intention is not 
allowed to assign a value to a non-intention identifier and ordinary 
code is not allowed to reference intention identifiers. We shall 
distinguish intention identifiers from ordinary identifiers by putting 
them in all caps. The intention 

<IHTIHD 

[-declarations-] ]predecessor| (expression) 

(function!> is exactly like the function intent except that intention 
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variables can be declared in the declaration. In addition ve need a 
function 

<0VEHA1L 

[-declarations-] {predecessor] ]expression I 
Ifunction|> which is exactly like the function I8TE8D except that it 
is used to state the overall intention of a procedure. If 
Jexpression] is a junction then the overall input output intentions of 
the junction are given by (predecessor! and (function!. Thus I8TEBDEH 
does computational induction across process boundaries. All the 
intentions in the function fact are true where 


Cdefine fact <function fact [n] 

<overall [] 

<intention [ ] 

<goal I'Cis? !'<non-neg> .n» 

<assert !*<is? !*<non-neg> ,n>» 

<repeat [[temp 1] [i 0]] 

!;<intention [] 

<prog [ ] 

<goal !*<is? !*<non-neg> ,i» 

<goal J*<= .teap ! *<factorial .i>»> 
<prog [] 

<assert !*<is? ! , <non-neg> . i» 
<assert !*<= . teap <factorial ,i>»» 

<cond 

[<is? . n .i> 

C.fact .teap> 

{"exit .fact with .teip"]> 

<_ :i <♦ .i 1» 

<_ :teap <* .i .teap»> 

<function [X] 

<intention [] 

<assert !•<= .X ! , <factorial .n»> 
<goal !*<= .1 !*<factorial .n>>»»» 


<define factorial <function [nl 
Coverall [] 

detention £ ] 
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<goal !'<is? ! , <non-neg> .n>> 

<assert !’<is? !*<non-neg> ,n>>> 

<cond 

[<is? C . n> 

1] 

[-"else” 

<* , n ^factorial <- .n 1»>]> 

<function [X] 

<intention [ ] 

<prog [ ] 

<cond 

[6<goal !*<- .n 0>> 

<assert !•<= .X 1»] 

£<goal !'<not !*<= . n 0»> 

<assert 
! '< = 

.X 

!'<* . n !*<fact !•<- .n 1>»» ]> 
<assert !•<= .X !'Combinations . n 0>» 

<assert !'<= .X !*<£act .n>>» 

<prog [ ] 

<qond 

[6<goal !'<= .n 0>> 

<goal !•<= .X 1»] 

[ 6<goal ! * <not !'<= .n 0»> 

<goal »'<= .X !'<* .n !*<fact !'<- .n 1»»>]> 
<goal !'<= .X !*Combinations .n 0>>> 

<goal !'<= .X I *<fact .n»»»»> 


The following is a protocol of the action of INTENDES on the 
intentions of fact: 


<assert ! Kis? !'<non-neg> n_» 
enter intentions of repeat 

Case 1: initial entry 
<assert !'<= 1 temp_>> 

<assert !*<= 0 i_>> 

<goal ! '<is?*”f *<ijon-neg> i_>> 

<goal !' <= 1 !'<factorial 0»> 

enter intentions of factorial 

n becomes 0 

X becomes 1 

<goal !'<is? !'<non-neg> 1» 
<goal !*<= 1 1» 

<assert !*<= 1 !*<factorial 0>>> 
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Case 2: inductively assuae 
<assert !*<is? !*<non-neg> i_>> 

<assert !*<= temp_ !*<factorial i_»> 
enter conditional 

Case 1: 

<assert !'<= n_ i_» 

<goal !'<= temp_ I Kfactorial n_>>> 

CciS€ 2* 

<assert !'<not !*<= n_ i_»> 

<assert !•<= i_1 !•<♦ i_ 1»> 

<assert !*<= 

temp 1 

!*<*“i_1 temp_»> 

<goal !’<= temp_1 !’<factorial i_1»> 
enter intentions of factorial 

n becomes i_1 

X becomes temp_1 

<goal !*<is? !*<non-neg> i 1» 

<gcal J * <= 0 i_1» 

FAIL 

<gcal 1*<= 
l«<* 

i_1 

!*<factorial !*<- i_1 1»> 
teap_1» 

On the other hand if INTENDEB analyzes the intentions of 


factorial ve get; 


<assert i'<is? !*<non-neg> n_>> 
enter conditional 


Casel; 

<assert !* <= 0 n » 

<goal !«<= I - ! *<fact C»> 
enter intentions of fact 

n becomes 0 
X becomes 1 
<goal !*<= 0 0» 
<goal !'<= 1 1» 



Case2: 

<assert !*<not !•<* 0 n_»> 

<assert ! 1 <= 

!'<factorial !•<- n 1» 
!«<fact !•<- n 1»>> 
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<goal !•<= 

!'<* 


n_ 

!*<factorial !•<- n 1>> 

! * <fact n_»>> 
enter intentions of fact 

n becoaes n_ 

X becoaes 

! »<* 

n_ 

J*<factorial !*<- n_ 1»> 
<goal !'<= ” 

! •<* 

n_ 

l*<factorial !*<- n_ 1»> 
!• Combinations n_ 0>>> 

<goal !* <* ” 

! •<* 

n_ 

l*<factorial *•<- n 1>» 

! »<* 


n_ 

! 7 <fact !•<- a 1»>» 


The intentions for the function fctrl defined belov are not so 
easy to establish. 


<define fctrl <function fctrl [n] 

<overall [[AEG .n]] 

<intention [] 

<goal !*<is? !»<non-neg> .n>> 

<assert !*<is? ! , <non-neg> .n»> 

<repeat [[temp 1]] 

!;<intention [] 

<goal 1'<* .teap !’Ccoabinations .AEG ,n»> 
<assert !*<- .teap I * <coabinat ions .AEG .n»» 

<cond 

[<is? 0 .n> 

<• fctrl . teap> 

;"exit .fctrl uith . teap"3> 

<_ :teap <* .teap .a» 

<_ :n <- . n 1»> 

<function [X] 

<intention [3 

<assert !•<* .X !•<factorial . ABG»> 

<goal !*<= .X I • <factorial ,ARG»»»» 
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He need to define an auxiliary function in order to do the proof: 


<define coabinations <function [nr] 

<overall [] 

<intention 

<and 

5<goal !*<is? !'<non-neg> ,n» 

&<goal !*<is? !*<non-neg> ,r» 

6<goal !*<is? !*<greater= .r> . n>>> 

<and 

£<assert !'<is? I*<non-neg> .n» 

6<assert !*<is? l # <non-n€g> .r» 

£<assert !*<is? I*<greater= .r> .n»» 

<cond 

[<is? -n .r> 

1 ] 

[-’"eise" 

<* .n Cccabinations <- . n 1> . f>>]> 

<function [X] 

<intention [] 

<prog [] 

<cond 

[8<goal ! *<= .n .r» 

<assert !•<= 1 „X>>] 

[£<goal !•<* .r 0» 

<assert !•<= . X !*<factorial . n»>]> 

<assert 


!•<= 

.X 

! *<* 

!'Ccoabinations !•< 
.n»» 

<Ptog [] 

<cond 

[£<goal !•<* .n .r» 

<goal !•<* 1 .X»] 

[<goal ! •<* .r 0» 

<goal !•<* .X !*<factorial . n>»]> 
<goal 

!•<* 

.X 

!'<* 

1*<conbinations I*< 
.n»»»»> 


•n 1> .r> 


• n 1^ *r^ 


IRTEHDEB yields the following protocol for the intentions of 


fctr 1 
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<assert !'<is? ! , <ncn-neg> n_>> 
enter intentions of repeat ~ 

Case 1: initial entry 

<assert !'<= 1 temp_>> 

<goal !•<= 1 !'<combinations n_ n_»> 

enter intentions of combinations 

n becomes n_ 

r becomes n_ 

<goal !'<is? !*<non-neg> n_» 
<goal !*<is? !*<non-neg> n_» 
<goal !'<is? !*<greater= n_> n_» 
<goal !*<= n_ n » 

<goal i*<= 1 1>> 

Case 2: inductively assume 
<assert 

!' <= 

temp_ 

! • <combinations n__ n__»> 
enter conditional 

facp 1 < 

<assert ! ’ <= 0 n_1» 

<goal !'<= temp_ ! *<factorial n_>» 
enter intentions of factorial 

n becomes n_ 

X becomes temp_ 

<gcal 

! ' <= 

temp_ 

! * Combinations n 


CdS€2 # 

<assert !’<not !'<= 0 n_1>>> 

<assert 

! • <= 

temp 1 

! * <*”temp n 1»> 
<assert !'<= n_2 !•<- n_1~1>~>> 

<goal !•<= 

temp_1 

J ^combinations n_ n_2»> 
enter intentions of combinations 

n becomes n_ 
r becomes n -> 2 
X becomes temp_1 
<goal !*<is? !*<non-neg> n_» 
<goal !*<is? !*<non-neg> n_2» 


0 »> 
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<goal !’<is? !*<greater= n_2> n_» 

<gcal !’<= 

temp 1 
! * <*“ 

!'Combinations 

n 

n”l> 

n_1»> 

He can use the same techniques for showing that a procedure 
will converge if its arguments satisfy certain conditions. The idea 
is tc define a partial order with no infinite descending chains and 
then prove that every time control goes through the same point in the 
program that it has descended in the partial order. The ordering we 
shall use is that [ SMALLES [Jal |b| |c|] [ |d| JeJ |f| ]] is true if one 
of the following three conditions holds: 

|a| is less than |d| 

|a!-|e) and |b| is less than ]e| 

|asj=je| and |b)=|e| and |c| is less than If) For example 
consider Ackerman's function as defined below: 


<define ackerman <function (z : y] 

<overall [] 

<intention [] 

<prog £ ] 

<goal I * <is? !'<non-neg> .z>> 
<goal !'<is? !’<non-neg> .x>> 
<goal !*<is? !*<non-neg> ,y>» 

<prog [] 

<assert !'<is? !'<non-neg> .x» 
<assert !*<is? !*<non-neg> ,x>> 
<assert !*<is? !'<non-neg> ,y>» 

smaller> 

<cond 

[<is? 0 .x> 

<rule [] .z 

[0 .y] 

£1 0 ] 

£<greater 1> 1 ]> ] 
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[<is? 0 .z> 

<+ 

<ackeraan 0 <- , x 1> . y> 
1 >] 

[“•"else” 

<ackerman 

<- .z 1> 

<ackernan .z <- .x 1> .y> 

• y>]> 

<function [»] 

<intention [] 

<assert !*<is? !*<non-neg> . w>> 
<goal !*<is? !'<non-neg> .¥»>>»> 


<define show-saaller <conseguent [abcdef] 

[smaller [?a ?b ?c] [?d ?e ?£]] 

<cond 

[£<goal !*<is? !'<less ?d> ?a»] 

[£<goal !•<= ?a ?d» 

<cond 

[£<goal !'<is? ! *<less ?e> ?b»J 
[£<goal !•<= ?b ?e>> 

<goal ! • <is? ! *<less ?f> ?c»] 
[-"else** <fail>]>] 

[-"else" <fail>]>» 

The protocol for PLAHNEfi on ackeraan's function is: 

<assert !*<is? !*<non-neg> z » 

<assert !*<is? !*<non-neg> x“>> 

<assert !'<is? !*<non-neg> y_>> 
enter conditional 

Case 1: 

<assert ! * 0 x_» 

<assert !*<is? l*<greater 0> x_>> 

Case 2: 

<assert !»<= 0 z_>> 

<goal [smaller 

[0 !»<- x. 1> y.] 

£0 X. y_33> 

enter shov-smaller 
a becomes 0 

b becomes !* <- x_ 1> 

c becomes y_ — 

d becomes 0** 

e becomes x 
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f becomes y_ 

<goal !*<is !'<less 0> 0>> 

FAIL 

<goal !•<= 0 0» 

<gcal !*<less i_> !*<- x_ 1» 

<assert !*<is? !'<greater 0> z» 

Case 3: 

<goal [saaller 

[z. !*<- x_ 1> y_] 

C*. Y_ ] ]> 

<goal [saaller 

£!•<- z 1> <ackeraan z !•<- x 1> y > y >] 

[2- X- 7_]]> 

He would like to show that if we reverse a list twice then we 
get the original list. 


<define reverse <function rev [1] 

<overall [ J 

t 

<repeat [[u .1 ] [v () ]] 

!;<iqtention [] 

<goal !*<is? .v !*<reverse !’<s«b .3 .u»» 
<assert !*<is? .v !*<reverse !*<sub .1 ,u»>» 

<coad 

[<eapty? .«> 

<.rev .v> 

; w exit .rev with .v»J> 

<- (<1 •«> i.v)> 

<_ :u <rest .u»> 

<function [X] 

<intention [ ] 

<and 

<cond 

[ <is? () .1> 

<assert i •<* .X ()»J> 

<assert !»<is? .X !*<rev . 1»> 

<assert ! *<is? .1 ! ( <reverse . X»>> 

<prog [] 

<cond 

[<is? 0 .1> 

S<goal !»<= .X ()"»]> 

S<goal !»<is? .X !»<rev .1»> 

6<goal l»<is? .1 !*<reverse .%»»»>» 
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We would like to show that for all |1J that <reverse <reverse |1|» is 
jl). Again we will need a helping function to express our intentions. 
We shall define <SUB |xj iy]> to be |x| subtract |yj as lists. 

<define last <function [xl 

<cond 

[<empty? <rest ,x>> 

<1 •x> 1 
[-."else” 

<last <rest . x>>]»> 

<define butlast <function [x] 

<cond 

[<enpty? <rest . x» 

0 ] 

[ -»”else" 

(<1 .x> <butlast <rest . x»]>>> 

<define sub <£unction fx y] 

<overall [] 

t 

Ccond 

[<is? .x ,y> 

0 ] 

[-"else" 

(<1 .x> (sub <rest . x>} .y) ]> 

<function [ Z ] 

<intenticn £] 

<cond 

£6<goal !*<is? .y () » 

<assert !*<is? .Z .x>>] 

£6<goal !*<not I »<is? .y ()»> 

<assert !•<* 

!*<last !*<sub .x !*<rest .y>» 

! * < 1 . y»> 

<assert !* <= 

.Z 

!*<butlast !*<sub .x !*<rest .y»»>]> 

<cond 

£$<goal !*<is? .y ()» 

<goal !*<is? . Z .x>>] 

[5<goal !*<not !'<is? .y () >» 

<goal !•<= 

!*<last !*<sub .x !*<rest .y>» 

! '<1 . y»> 

<goal !'<= 

.Z 

!'<butlast !*<sub .x !'<rest 


y »»>]»»» 
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<define rev <function [list] 

<overall [ ] 

t 

<cond 

[<monad? .list> 

.list ] 

[ -* M else n 

(<last .list> {rev <butlast .list>}) ]> 

<function [X ] 

<intention [ ] 

<prog [ ] 

<assert !*<is? .X !’<reverse .list>» 
<assert !'<is? .list t*<reverse ,X»» 

<prog [ ] 

<goal !*<is? .X !*<reverse ,list>» 

<goal !*<is? .list !*<reverse .X»»»>» 


The protocol of INTENDEB on HEVEBSE is: 

enter intentions of repeat 


Case 1: initial entry 
<assert !•<* u_ 1_» 

<assert !' <= v_ () » 

<goal !*<is? () !'<reverse ! *<sub 1_ 1_»» 
enter intentions of sub 


x becomes () 


y becomes {) 

<assert !•<= {) !*<.sub 1_ 1_>» 
enter intentions of reverse 

1 becomes () 

<assert !•<= {) IKreverse () »> 


Case 2: inductive hypothesis 

<assert !*<is v_ !*<reverse !*<sub 1_ u_>»> 

enter conditional 


Case 1: 

<assert !' <= () u_» 

enter overall consequent 
X becomes v_ 

<goal ! • <is v_ !*<reverse 1_>» 

<assert !'<not !*<= {) u_»> 

C^s>m 2 * 

<assert !•<= v_1 (!*<1 u_> !* {value v})» 
<assert !*<= u_1 !*<rest u_»> 

<goal !'<is 

( 


! * <1 u > 
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!•{reverse J*<sub 1_ u_>3) 

!’<reverse ~ 

!* <sub 

1 _ 

! * <re.st u_»»> 

Allowing shared side effects in structured data considerably 
complicates the process of proving intensions. 

7.1.2 Hodels in Patterns: Ains 

Aims are like intentions except that they are actors and occur 
in patterns. 

<AIH predecessor pattern down up successors> is the form for a 
call to the actor aim. An aim will be said to be attained when the 
following conditions are satisfied: 

[1] Its predecessor evaluates to true 

[2] We apply the function down with two arguments. The first 
is the expression to be matched. The second is <> if and only if 
pattern doesn't match. 

[3] We apply the function up with two arguments. The first 
is <> if and only if the rest of the pattern doesn't match. The 
second is <> if and only if pattern fails. 

[4] The successors evaluate to true. 

The function down expresses the intent of the downward action of the 
pattern and the function up expresses the upward going action. The 
actor <AIflING [declarations] predecessor pattern down up successors> 
is exactly like the actor AIH except that intention variables nay be 
declared. For example the aim in the folowing expression is 
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attained: 


<aiming [[OLD-F .f]] 

_£ 

<£unction [I Y] 

<assert l*<eg .f ,X>> 

<assert !*<is? t>» 

<function [X Y] 

<cond 

[6<goal ! *<is? .X <»> 

<assert ! *<eg .f .OLD-F» 

<assert !*<is? ,Y []>>] 

[6<goal ! '<is? .X t» 

<assert !*<eg .f ,X>> 

<assect !' <is? .▼ t» ]»> 

The value of f changes only if the rest of the match succeeds. The 
actor <EBTIBE [declarations] predecessor pattern down up successors> 
is exactly like the actor AIMING except that it is used to express the 
entire intent of the pattern. For example for the actor ATOMIC which 
takes no arguments and matches only atoms can be characterized by: 


<define atomic <actor [] 

<entire [] 

<atomic> 

<function [X X] 

<cood 

[ 8<goal 1 *<atom ,X» 

<assert !»<is? .Y t>>] 
[8<goal ! *<not !*<atom .X»> 

<assert !»<is? .1 <»>]» 

<function [X I] 

<assert !*<is? .X .Y»>»> 


7.1.3 Models of PLAHNEB Theorems 
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We shall construct models for EL&8NEE theorems in much the 

same manner as for MATCHLESS patterns. 

<THINTENT predecessor x down up successors> is true if the 
following conditions are met: 

£1] the predecessor is true. 

[2] We apply the function down with two arguments: The first 
argument is <> if and only if the evaluation of x fails. If the first 
argument is not <> then the value of the second argument is the value 
of x. 

£3] We apply the function up with four arguments. The first 
is <> if and only if the rest of the computation fails. If the first 
argument is <> then the second argument is the message of the failure. 
The third argument is <> if and only if the evaluation of x fails. If 
the third argument is not <> then the fourth argument is the value of 
x. 

The function TBINTENt is exactly like the function THINTEHT 
except that a declaration of intention variables must be the first 
argument. For example the folliwng intention is always satisfied: 
Becall that the function ASSEBT1 will assert a statement if has not 
already been proved. 

<thintend £[already-proved <>]] 

t 

Cassertl [subset a b ]> 

<function [I Y] 

<cond 

£S<goal £ proved £ subset a b]]> 

<assert !'<is? .X <»> 

<_ :already-proved t> 
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<assert !’<is? .1 <»> ] 

[6<goal l f <not [proved [subset a b]]» 

<assert [proved [subset a b]]> 

<assert !*<is? .X t» 

<assert !*<is? . Y [subset a b ]>>]>> 

<function [X Y U V] 

<cond 

[<is? .already-proved> 

<ccnd 

[ 8<goal ! * <is? .X <»> 

<erase [proved [subset a b ]]>]>]> 
<assert !*<is? .0 .X» 

<assert !'<is? .V .Y»» 
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7.2 Teaching Procedures 

Crucial to our understanding of the phenomenon of teaching is 
the teaching of procedures. Understanding the teaching cf procedures 
is crucial because of the central role played by the structrual 
analysis of procedures in the foundations of problem solving. How can 
procedures such as multiplication, algebraic simplification, and 
verbal analogy problem solving be taught efficiently? Cnee these 
procedures have been taught, how can most effective use of them be 
made to teach other procedures? In addition to being incorporated 
directly as a black box, a procedure which has already been taught can 
be used as a model for teaching other procedures with an analogous 
structure. One of the most important methods of teaching procedures 

is telling. For example one can be told the algorithm for doing 
symbolic integration. Telling should be done in a high level goal- 
oriented language. PLANNEB goes a certain distance toward raising the 
level of the language in which we can express a procedure to a 
computer. The language has primitives which implement fundamental 
problem solving abilities. Teaching procedures is intimately tied to 
what superficially appears to be the special case of teaching 
procedures which write procedures. The process of teaching a 
procedure should not be confused with the process of trying to get 
the one being taught to guess what some black box procedure really 
does [as is the case in in sequence extrapolation for example]. The 
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teacher is dutj bound to tell anything that Bight help the one being 

taught to understand the properties and structure of the procedure. 

We assume that the teacher has a good model of how the student thinks. 
Also, just because we speak of "teaching”, we do not thereby assume 
that anything like what classically has been called learning is taking 
place in the student. However, this dees not exclude the possiblity 
that the easiest way to teach many procedures is through examples. We 
can give protocols of the action of the procedure for various inputs 
and enviroments. By "variablization" [the introduction of identifiers 
for the constants of the examples] the protocols can be formed into a 
tree. Then a recursive procedure can be generated by identifying 
indistinguishable nodes on the tree. We call the above procedure for 
constructing procedures from examples the procedural abstraction of 
protocols. Procedural abstraction can be used to teach oneself a 
procedure. 

7.2.2 By Procedural Abstraction 

7.2.2.4 Examples of Procedural Abstraction 

7.2.2.4. 1 Building a Wall 

We shall explain procedural abstraction in more detail using 
the example of building a wall. We define <brick-at ]wj |h|> to mean 
that there is a brick at the location with width |u| and height |h| 




BUILDING WALLS 


(+. 2 ) 

(<#>, I ) 
(<#>,<£) 

[WALL I 2] 


<<#>.!) 

(Mi 

(<£ 4 >) 

(!,<#>) 


[WALL 2 I] 


note: the numbers in the boxes represent 

THE COORDINATES OF THE BRICKS. 
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and define the stateliest [vail ]v| |h|] to mean that there is a wall 
of width w and height h using the definition 


<define wall <function [w h] 

Conjunction [[ww 0]] 

[-'’’inc” ww -•’’by” 1 -'’’thru” .w] 

<conjunction [[hh .h]] 

[ -."dec” hh -.’’by" 1 -’’thru” 0] 
<brick-at .ww .hh»>>> 

Thus <wall 1 2> means 


<and 

<and 

<brick-at 0 2> 

<brick-at 0 1> 

<brick-at 0 0>> 

<and 

<brick-at 1 2> 

<brick-at 1 1> 

<brick-at 1 0>». 

Noticethat the syntactic definition ofa wall runs orthogonaltothe 
way in which a wall has to be constructed. Thus we could not use 
purely syntax directed methods to construct walls. The predicate 
<ASSIGNED? var> is true only if the identifier var has been assigned a 
va 1 ue. 


<define build-tower 
Consequent build 

[£!=fix w h] [actions []]] 

£brick-at ?v ?h] 

<cond 

[<not? <assigned? h>> 

<_ .h 0>]> 

<cond 

[<corrent? [brick-at ?w ?h ]> 

<.build () > 

;"exit .build with () ]> 

[<is? .h 0> 

<. build (! *<put-brick-at ?w ?h>) > ]> 
<_ :actions <gcal [brick-at ?w <- .h 1> ]» 
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<goal [ put-brick-at ?w ?h]> 

<goal [check-brick-at . w .h]> 

<assert [brick-at .w .h]> 

<. build (i.actions !*<put-brick-at ,w .h>)» 

If we give PLANNER the task cf constructing a [wall 1 2], then the 
actions that vill be taken are: 

<put-brick-at 0 0> 

<put-brick-at C 1> 

<put-brick-at 0 2> 

If the goal is [wall 2 11 then the actions are: 

<put-brick-at C u> 

<put-brick-at 0 1> 

<put-brick-at 1 0> 

<put-brick-at 1 1> 


He shall use the expression new 5 to Bean that a new identifier is 

bound and initialized to 5. He shall use the expression <value 9> to 
nean a reference to an identifier whose value is 9; the expression 
<alter 3 7> Beans that an identifier with value 3 is altered to be the 
value 7. Hore precisely, the protocol for [wall 1 2 ] is 


<new [121 

<new [UNASSIGNED UNASSIGNED] 

<_ <alter UNASSIGNED C> 0> 

<Is? <value 0> <value 1» IS FALSE 
SO 

<_ <alter UNASSIGNED C> 0> 

<Is? <value 0> <value 2» IS FALSE 
SO 

<put-brick-at <value 0> <value 0» 

<_ <alter 0 1> <♦ <value 0> 1» 

<is? <value 1> <value 2>> IS FALSE 
SO 

<put-brick-at <value 0> <value 1>> 

<_ <alter 1 2> <♦ <value 1> 1>> 

<Is? <value 2> <value 2» IS TRUE 
SO 

<_ <alter 0 1> <♦ <value 0> 1» 
<is? <value 1> <value 1» IS TRUE 
SO 


C 3» 
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The protocol for [wall 2 11 is 
<nev [2 1] 

<new [UNASSIGNED UNASSIGNED] 

<_ <alter UNASSIGNED 0> 0> 

<is? <value 0> <value 2» IS FALSE 
SO 

<_ <alter UNASSIGNED 0> 0> <is? <value 0> <value 1» IS FALSE 
SO 

<put-brick-at <value 0> <value 0>> 

<_ <alter 0 1> <•*■ <value 0> 1» 

<is? <value 1> <value 1>> IS TRUE 
SC 

<__ <alter 0 1> <♦ <value 0> 1>> 

<is? <value 1> <value 2>> IS FALSE 
SC 

<_ <alter 1 0> 0> 

<is? <value 0> 1>IS FALSE 
SO 


<put-brick-at <value 1> <value 0» 
<_ <alter 0 1> <♦ <value 0> 1» 
<is? <value 1> <value 1» IS TBUE 
SC 


< 



<alter 1 2> 

<♦ < value 1> 1» 


<is? 


<value 2> 

<value 2» IS TBUE 
SO [ ]» 


The protocol for [wall 2 2 ] is 
<new [2 1] 

<new [UNASSIGNED UNASSIGNED] 

<_ <alter UNASSIGNED 0> 0> 

<is? <value C> <value 2>> IS FALSE 
SO 

<_ <alter UNASSIGNED 0> 0> 

<is? <value 0> <value 2» IS FALSE 
SO 

<put-brick-at <value 0> <value 0» 
<_ <alter 0 1> <♦ <value 0> 1>> 
<is? <value 1> <value 2» IS FALSE 
SO 

<put-brick-at <value 0> <value 1» 
<_ <alter 1 2> <♦ <value 1> 1» 
<is? <value 2> <value 2» IS TRUE 
SO 

<_ <alter 0 1> <♦ <value 0> 1>> 
<is? <value 1> <value 2» IS FALSE 
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SO 

<_ <alter 2 C> 0> 

<is? <value 0> <value 2>> IS FALSE 
SO 

<put-brick-at 1 0> 

< <alter 0 1> <♦ <value 0> 1>> 

<Is? <value 1> <value 2» IS FALSE 
SO 

<put-brick-at <value 1> <value 1» 

<_ <alter 1 2> <♦ <value 1> 1» 

<” <alter 1 2> <+ <value 1> 1>> 

<Is? <value 2> <value 2» IS TROE 
SO 

[ ]» 

By introducing identifiers fcr the constants and by tracing the 
bindings of the identifiers of BUILD-TCNER the protocols can be 

arranged in a tree as follows: 
new [w h] 

new Xww= ONASSIGNED; hh=UNASSIGNED] 

<_ :ww 0> 

if <is? .ww .w> 

then 

[3 

else <_ :hh 0> if <is? .hh .h> 
then 

<_ ; ww <♦ .ww 1» 
if <is2 .ww .w> 
then 

[3 

else 

< :hh 0> 

if <is? .hh 0> 
then 

<_ :v« <+ .ww 1» 

if <is? .ww .w> 
then 

C 3 

else... 

else... 

else 

<put-brick-at .ww .hh> 

<_ :hh <♦ .hh 1» 
if <is? .hh .h> 
then 

<_ :ww <♦ .ww 1» 
if <is? .ww 1> 
then 

[3 
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else 

< :hh 0> 
if <is? .hh .h> 
then 

<put-brick-an . ww .hh> 

< :hh <+ .hn 1>> 

if <is? .hh ,h> 
then 

<_ :vv <+ .ww 1» 
if <is? .vv .w> 
then [] 
else... 

else... 

else... 

else 

< :hh <+ .hh 1» 
if <is? .hh .h> 
then 

<_ : w <•*• . ww 1>> 
if <is? .ww .w> 
then [] 
else... 

else... 


He define the protocol of an evaluation to be a list of the 

events and the places in the program where they happen that occur when 
the evaluation is being carried out. By examining the protocols of 
the system as it tries to build a wall we find that it always uses the 
same procedure, of course it will not always be the case that the 
protocols from the solutions of the instances of a goal can be 
combined into a procedure. The basic idea is to combine the set of 
protocols into a tree and then consider any two nodes of the tree 
which cannot be distinguished on the basis of the protocols to be 
identical. In other words it is necessary to compute a minimal or 
almost minimal homomorphic image of the set of available protocols. 
Unfortunately it is often difficult to extract the information needed 
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to do procedural abstraction from the protocols produced by PLANNEB 

theorems as they solve problems. The procedure that the theorem is in 
fact using can be expressed as follows: 


<define compile-build <function [w h] 

<overall [ ] 

!;<intention [J 
<and 

<goal l*<is? !’<non-neg> ,w» 

<goal !*<is? !*<non-neg> . h»>> 

<and 

<assert !’<is? !*<non-neg> . w» 

<assert !*<is? !*<non-neg> ,h>»> 
<repeat column 
[[*" 0 ]] 

!;<intention [ ] 

<goal [wall .vu .h]> 

<assert [wall .ww .h]>> 

<cond 

[<is? .ww ,w> 

<intent <wall .w . h>> 

<.column> 

;"exit .column"]> 

<repeat height [[hh 0]] 

!;<intenticn [ ] 

<goal [column .ww ,hh]> 

<assert [column .ww .hh]>> 

<cond 

[<is? .hh . h> 

<.height> 

;"exit .height with <>" ]> 
!;<intent <goal [support-for .ww . hh]>> 
<put-brick-at .ww . hh> 

!;<intent <goal [brick-at .ww ,hh]» 

<_ :hh <+ .hh 1»> 

<_ :ww <♦ .ww 1»> 

<function [X] 

<assert [wall .w .h]> 

<goal [wall .w .hj»» 

<define check-wall 
<consequent 

check-wall 
[w* w h* h] 

[wall ?w* ?h* ] 

<cond 


[<or? 
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8<goal ! *<is? ?h« 0» 
5<goal !'<is? ?w* 0»>] 
[<is? !*<♦ ?b 1> .h'> 


<goal 
<goal 
[<is? !•<♦ ?w 

<goal 

<goal 

[ -•"else" 


[wall ?w* ,h]> 
[column ?w * ?h* ]>J 
1> ,w»> 

[wall ?w .h* ]> 
[column ?w* ?h']>] 


<fail <> .check-vall> j»> 


<define check-column 
<conseguent 

check-column 

[w h h*] 

[column ?w ?h•J 

Ccond 

[5<goal ! *<is? ?h' 0»] 

[<is? !*<♦ ?h 1> ,h»> 

<goal [column ?w ?h]>] 

[ -••’else*’ 

<fail <> .check-colunn> ]>» 


<define check-support 


check-support 
[w h] 

[support-for ?w ?h ] 

<cond 

[S<goal !*<is? ?h 0»] 

[<goal [column .ww . hh]>] 

[ -•"else'' 

<fail <> . check-support> ]»> 


<define put-brick-at 
<£unction [w h] 

<overall [J 

<goal [support-for . v .h]> 

<put-brick-at .w .h> 

<assert [ brick-at .w ,h]>>» 

The IHTEHDEB protocol for the verification of the intentions 
of compile-build is; 


<assert !*<is? ! f <non-neg> w_>> 
<assert i*<is? !*<non-neg> h~» 
eater intentions of repeat ~ 
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Case Is initial entry 
<assert !*<is? 0 ww_» 

<goal [wall 0 h ]> 

enter intentions of check-wall 

w* becomes 0 
h* becomes h 
<goal ! * <is?~h_ 0» 

FAIL 

<goal ! * <is? 0 0» 

Case 2: Inductively assume 
<assert [wall ww_ ri_ ]> 

enter conditional 
Cel S© 1 • 

<assert !*<is? u_ ww_» 

<goal [wall w_ h_]> 

C&S€ 2* 

<assert I'Cnot !*<is? w_ ww_»> 
enter intentions of repeat 

Case Is initial entry 
<assert !*<is? 0 hh_>> 

<goal [column ww_ hh_]> 

enter intentions of check-column 
w becomes ww_ 
h* becomes hh_ 

<goal !'<is? 0 hh_» 

Case 2: inductively assume 
<assert [column ww_ hh_ ]> 

enter conditional 
Case 1: 

<assert l'<is? hh_ h_» 

<assert !*<is? ww_1 !*<♦ ww_ 1»> 

<goal [wall ww_1 h_]> 

enter intentions of check-wall 

w* becomes ww_1 
h* becomes h 

<goal I'Cis? !*<♦ ?h 1> h_1» 
v becomes w_ 

<goal [wall ww_ h_]> 

CdS€ 2 * 

<assert !*<not !*<is? hh_ h_»> 

<goal [support-for ww^ hh_]> 
enter intentions of check-support 

w becomes ww 
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h becomes hh_ 

<goal [column ww_ hh_]> 
<assect !'<is? hh_1 !*<♦ hh_ 1»> 
<goal [column wv_ hh_1 ]> 
enter intentions of check-colunn 

w becoaes ww_ 

h' beccaes hh 1 

<goal ! *<is? !•<♦ ?h 1> hh. 

h becoaes hh_1 

<goal [coluan ww_ hh_1]> 


1 » 


Note that the above proof that COMPILE-BUIID meets its 

intentions is relative to the PROCEDURAL MODEL that we have 

constructed. The procedural nodel is constructed out of procedures 

such as PUT—BRICK”AT. The procedural nodel is connected to our goal 

oriented language by CORRESPONDENCE BUIES such as CHECK-SUPPORT. 

The structure of the abstracted procedure Bust at least 

reflect the structure of the PLANNER theorems froa which it has been 

/""‘N . ..■.,, 

abstracted. Thus the abstraction of a for-proved loop will generate 

a recursive equation which might be simplified to a loop. Soae of the 

recursion in abstracted functions is primarily generated by the 

structure of the data of the problea. If we consider the tags coluan 

and height to define functions, then the proof is essentially by 

recursion induction. In the above procedure .w is the width of the 

wall to be built, .ww is a running index over the width, .h is the 

height, and .hh is a running index over the height. Using the 

intentions in the above procedure as subgoals we can easily see that 

the procedure does build walls. Notice that we can use the protocols 

of the procedure [in a process that we call "protocol rejection"] to 

reject false subgoals in such the saae way that Gelernter used 

diagrams in his geometry theorem prover. Por example we might 


y-\ 
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evaluate <compile-build 1 2>, Ccompile-build 2 1>, and <ccmpile-build 

3 2> remembering the protocols of the evaluations. Thus when 
considering the case where the intention 

<intent 

<or 

<is? ,ww 0> 

<wall <sub1 .ww> . hh»> 

is evaluated immediately after <end column> is evaluated, it will be 

the case that <is? .ww 0> is false and so cannot possibly be a 
provable subgoal even though it implies the intention. The subgoal 
will be to prove [implies <not <is? .w 0» <wall <sub1 .ww> .hh>]. Of 
course using protocols for the purpose of rejecting false subgoals 
does not help us to eliminate those that are true but unprovable. 

7.2.2.4.2 fieversing a list at all Levels 

Consider the following protocols for a procedure r: 


<new [a] 

<is? <monadic> <value a>» IS TBUE 
SO <value a> 

thus <r a> is a 


<nev [£n]] 

<is? <aonadic> <value [n]» IS FUSE 
SO 

C 

{new [ <rest <value [nj»3 
<is? <monadic> <value []» is TBOE 
SO <value []>} 








Cnew [CCvalue [ n ]> 1>] 

Cis? Cnonadic> Cvalue n>> IS TBUE 
SC <value n>>]> 

thus Cr [ n ]> is [ n ] 


Cnew [[a b]] 

<is? Cnonadic> Cvalue [a b]>> IS FALSE 
SO 

[ 

{new [ <rest <value [a b]>>] 

<is? Caonadic> <value [bj>> IS FALSE 
SO 

[ 

{<new (<rest <value [b]>>] 

<is? <nonadic> Cvalue []>> IS TRUE 
SC Cvalue [ ]>>} 

<new [CCvalue [b]> 1>] 

<is? <ionadic> <value b>> IS TBUE 
SC <value b»]} 

<new [CCvalue [a b j> 1>] 

Cis? <aonadic> Cvalue a>> IS TBUE 
SC <value a» ]> 

thus <r [a b3> is [b a 3 


<nev [[[ a]]3 

<is? <nonadic> <value [[a3 3» IS FALSE 
SO 

C 

{<nev [<rest <value [[a33>>] 

<is? <acnadic> Cvalue [3>> IS TRUE 
SO [3>) 

Cnew [CCvalue £ £ a ] 2> 1>3 
Cis? CacnadiO Cvalue [a]» IS FALSE 
SO 

C 

{Cnew [Crest Cvalue [a]»3 
Cis? Cmonadic> Cvalue [3» IS TBUE 
SC [ 3>} 

Cnew [CCvalue (a]> 1>3 
Cis? Caonadic> Cvalue a>> IS TBUE 
SO Cvalue a>>]>]> 

thus <r[[a]3>is[[a]3 


We obtain the following protocol tree: 



<new £ xl] 

if <is? <aonadic> .x1> 
then .xl 
else 

[ 

(new £x2 <rest .x1>] 
if <is? <aonadic> ,x2> 
then .x2 
else 

[ 

{new [x3 <rest .x2>] 
if <is? <aonadic> .x3> 
then .x3 
else...} 

<new £x4 <1 .x2>] 
if <is? <aonadic> ,x4> 
then ,x4 
else. .. > ]} 

<new £x5 <1 .x1>] 
if <is? <aonadic> .x5> 
then .x5 
else 

[ 

{new £x6 <rest .x5>] 
if <is? <acnadic> .x6> 
then .x6 
else...} 

<new £x7 <1 .x5>] 
if <is? <acnadic> .x7> 
then .x7 
else. ,.>]>]> 


By identifying indistinguishable nodes 

<define super-reverse <function £x] 

<cond 

£<is? <aonadic> .x> 

.x ] 

£-*"else w 

[ 

{super-reverse 
<snper-re verse 
7.2.2. 4.3 Finding the Description of a 
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we obtain: 


<rest . x>} 


<1 .x»]]»> 
Stick 



Suppose that we have the following data base: 
[block a] 

[block b] 

[glued a b] 


The above data base represents a stick on the the basis of the 
following protocol: 


<goal [stick a bj> 

<new [ONASSIGNED UNASSIGNBD ONASSIGNED 


values'* 


;"»e have three new 


1 


that do not have 


consequent: [stick <given ONASSIGHED a> <given ONASSIGNED b>] 


<current [glued <given a> <given b>1> 
<return t>> J 


How suppose that the data base is: 

[block a] 

[block b] 

[block c] 

[glued a b] 

[glued b c] 

[between a b c] 


He obtain the following protocol: 


<goal [stick a cj> 

[new UNAsSIGNED ONASSIGNED UHASSIGNED] 

consequent: [stick <given a> <given c>l 
cond J 


<current [glued <given a> <given c>l> 
fail J 

<current [block <given a>]> 

<goal [glued <value a> < UHASSIGNED b>]> 

<current [between <value a> <value b> <given c>l> 
<goal [stick <value b> <value c>]> 

[new ONASSIGNED ONASSIGNED UNASSIGHED1 

consequent: [stick <given b> <given c> 1 
cond J 


<proved [glued <given b> <given c>1> 
<return t> ^ 





[block b 1 
[glued a bl 

FIGURE I 



[block a] 

[block b3 
Cblock c] 

[glued a b3 
[ glued b c3 
C between a b c3 

FIGURE 2 


[block a3 
Cblock b3 
[block c3 
[glued a b3 

[glued b c3 

[not[between a b c33 



FIGURE 3 


/ 
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By variabalization ve obtain the following protocol tree: 

<goal [stick u vl> 

[new x y 2 ] 

consequent cl: [stick ?x ?zl 
<cond 

[6<goal [glued lx ?z]> 

<.c1 t> 

{"exit «c1 with t" ]> 

<current [block ?x]> 

<goal [glued .x _y]> 

<current [between .x .y ?z J> 

<goal [stick .y .z ]> 

(new x 1 y1 zl] 

consequent c2: [stick ?x1 ?z1] 

<cond 

(6<goal [glued ?x 1 ?z1]> 

<.c2 t> 

{"exit .c2 with t" 1> 

<current [block ?x1]> 

<goal [glued .xl _y1]> 

<current [between*.xl .yl ?z11> 

<goal [stick .yl .zl ]> 

By identifying indistinguishable nodes we obtain the following 
consequent theorea which is the description of a stick. 


<define stick-description <ccnsequent c 

[ s y z ] 

[stick ?x ?z] 

<cond 

[6<goal [glued ?x 7zl> 

<• c t> 

•"exit ,c with t"]> 

<current [block ?x]> 

<goal [glued .x _yj> 

<current [between «x ,y ?zl> 

<goal [stick ,y .zj»> 

7.2.2.4.4 Finding the libonocci luabers Iteratively 
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Sometimes it is possible to improve the efficiency of a 
procedure by procedural abstraction, for example consider the 
protocols of the schema f defined below. 


<define 


f <function [n] 

Ccond 

[<or <P .n> <P <S .n>» 

<OHE>] 

[ -.“else** 

<1 <f <S .n» <f <s <S 


.n»»]>» 


we shall used the abbreviation that <f-0 x> is x and <f-n+1 
<f-»n x» where f is a function. Thus <f-*2 x> xs <f <f x». 
protocol for the above schema is: 

if <or <P <S-*0 n» <P <S-*1 n»> 
then <OHE> 


x> is 
The 


<f 


<K 


if <or <P <S-1 n» <P <S-*2 n»> 
then <GHE> 


<A 


if <or <P <S-'2 n» <P <S-*3 n»> 
then <CBE> 


if Cor <P <S-»3 n» <P <S-*4 n»> 
then <OBE> 
else...> 

if <or <P cs-*2 n» <P cs-3 n»> 
then <CBE> 


<h 


if <or <P <S-.3 n» <P <S-.4 n»> 
then <OHE> 


• • e 


if Cor <P CS-4 n j>> <P CS-»5 n»> 
then <OHE> 
else..♦ >> 


By procedural abstraction we can obtain a function fl which : 

eguivalent to f. rhe function is obtained by identifying sene or tie 
nodes that are not on the same branch of the protocol tree. 
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<define £ <function oat fnl 

<cond L J 

£<or <P . n> <p <s . n»> 

< * oat <OHE> <CNE»] 

[ -i "else" 

<call 

<f <s .n» 

<f unction [downl down2] 

<.out 

<A .dovnl .down2> 
.down1>»]>» 


Another approach is to use sene of the theory of recursive schemas. 

The function f defined above is schematically eguivalent to the 
function ff defined below 


<define ff <£unction ff fnl 

<for £[x 0] [y o , )] J 




[[-'"test* <P ,n> <.ff ,x> ;"exit .ff with 
[-'"step" <_ :n <s .n»J] 

[:x :y] <tuple <A .x .y> ,x» 

; K tbe previous statement is just a tricky way to 

simultaneously accomplish < :x <A .x .y» 
and <_ : y .x>"»> 



Mote that <£ib n> the 


nth Fibonacci number can be defined as follows 


<defxne fib <function [n] 

<cond 

£<or <is? 1 «n> <is? 2 .n» 

1 ] 

[-'"else" 

<♦ <fib <- .n 1» <- .n 2»J»> 


Osing the interpretation that <0ME> is 1, <P x> tests to see if x 

1r ana a is add, we see that the function fib can be rewritten 
iteratively. 

The process of procedural abstraction is very much like * 
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generalized fora of ccapilation. The relationship between the 
compiled version and the interpreted version can be very subtle. In 
classical compilers the relationship is auch more straightforward. 

Every time that the interpreter for the language changes the comniler 
aust change. In fact the interpreter and compiler are two mooes of 
what is essentially cne program: an interpreter-compiler. In compile 
mode it would actually produce the coapiled code for the source code; 
in interpret mode it would take the actions corresponding to the 
compiled code that would be produced in compile mode. The 
interpreter-compiler can be written it MATCHLESS so that in compile 
mode the HATCHLESS skeletons have as value the compiled code. One 
problem with interpreter-compilers is that they suffer from the 
inefficiency of double interpretation- Instead of directly 
interpeting the expressions, in interpret mode thO interpeter-coipiler 
interprets the skeletons that would produce the code in compile mode. 
The problem can be solved by compiling the interpreter-compiler for 
interpret mode. He would like to try to extend this idea to PLA8NEH 
in a more nontrivial way so that joals would be created to produce the 

compiled code. 

7.2.2. 4. 5 Defining a Data Type 

He can do procedural abstraction of protocols along the same 
lines for actors. For example if we obtain the following actor 
protocol 




£<when 
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CC ]] 

[<atoaic>] 
£<when 


{when 


CC 3 3 

£<atoaic>] 

£<when 

CC 33 

£<atcaic>]>]> 

CC 33 

£ <atcaic>J 
£<when 

CC 33 

£<atoaic>] 

£ <when 

CC 33> 

(when 

CC 33 

£ <atoaic> ]} ]> ]} ]>] 


Then by identifying equivalent nodes we obtain the actor 


expr where 


<define expr <actor £j 

<wben 

CC 33 

£<atoaic>] 

££<expr> {expr)J]»> 

Goodstein has aany inductive proofs of the the properties of 
recursive prograas. John Hccarthy was one of the first to popularize 
the use of recursion induction for proving the properties of prograas. 
The easiest way to do recursion induction is to provide at least one 
predicate for each recursive equation, fiobert Floyd has proposed that 
predicates in the first order guantificational calculus be attached to 
the edges of flow charts in order to provide subgoals for proofs of 
properties of prograas. in general we would prefer to proceed aore 
constructively and to write intentions in PLANNEE rather than in a 
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fora of the guantificational calculus. Finding aij intuitionistic 

proof of a sentence in first order logic is the same problem as 
finding a recursive function that realize the the formula. Since the 
logistic system of PLANNER is very constructive, a proof of a PLANNER 
theorem entails being able to write the procedures which compute the 
values that identifiers in goals take on as a result of the goal being 
established. Intentions are a first step toward constructing models 
of the environment in which a process executes. Se need to develop 
good ways to increase the expressive power of intentions. Currently 
the lodel of the computation must be expressed by intentions within 
the process being executed which makes it difficult to get a global 
view of the model of the execution of the process. The application of 
intentions in which we are most interested is their use to provide 
subgoals to enable us to deduce PLANNER theorems with loops in them. 

He shall say that an intention i characterizes a function f if 
whenever <f x> converges then <equal <f x> y> if and only if <i x y> 
is true. A long time ago John acCarthy and others proposed that tne 
debugging problem be solved by proving that the procedure is correct 
once and for all. Using induction McCarthy and his students have 
proved that certain compilers are correct. The most important 
practical difficulty to the realization of the proposal is that for 
many functions f written in higher level languages it seems that all 
the intentions that characterize f are at least as long as f because 
the only way to tell whether the value of <f x> is correct or not is 
to do an equivalent computation all over again. A good example of 
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such a function is eval in LISP. The function eval is an extreme 

exanple of a function that has no siaple declarative input ouput 
characterization. A real challenge in automatic prograa writing is 
to develop a systolic inetegration routine from the criteria that the 
derivative of the answer aust be equivalent to the input. One 
approach toward constructing such a routine would be to make use of 
sone results of Bisch on what aust be the fora of the integrand as a 
function of the fora of the integrand. In the case of the factorial 
function there are two obvious ways to coapute the function: using 
recursion or using a loop, in other cases it is net so obvious how to 
find a sufficiently different equivalent prograa. We shall say that 
an intention i is iaplied by a function f if whenever <f x> converges 
then if <egual <f x> y>, then <i x y> is true. Iaplied intentions are 
useful when we are only interested in sone property of the function 
and don*t care to try to characterize it completely. For example we 
might not care whether a function that deteraines how to stack cubes 
always puts red cubes on the botton of the tower that it is trying to 
build. or we aight be interested in proving that a scheduler for a 
tiae sharing system passes soae test for fairness in its distribution 
of tiae to users. Another potential use for iaplied intentions is to 
provide subgoals to prove that a given function that uses lock and 

unlock and unliaited use of assignment in parallel computations is 
indeed deterainate. 

A more serious problem is that often we cannot develop 
reasonable iaplied overall intentions, consider trying to write 
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intentions for a chess program. He could require that the program 

play LEGAL chess but this is the least of considerations. How can we 
write intentions to the effect that the program should play GOOD 
chess? There is a completely trivial program which will play PERFECT 
chess given sufficient time and storage. However, the amount of time 
and storage required are wildly impractical. One sight believe that 
the problem of writing overall intentions afflicts only game playing 
programs. However, the same problem arises in trying to write 
overall intentions for a robot. He can specify in detail a certain 
finite number of elesectary procedures which the robot should be able 
to perform. In a given situation there nay be some obscure way for 
the procedures to interract to provide a solution for a problem. 
However, it is not fair to blame the robot for not solving a very 
difficult problem. Thus we again have a problem writing realistic 
overall intentions. 

7.2.3 Teaching Procedures by Deducing the Bodies of Canned Loops 

If the type cf control structure is Known a priori, then the 
rest of the function can often be deduced. Often the control 
structure needed is a very commonly used loop such as the FOB loop in 
HATCHLESS, recursion on the tree structure of lists, or one of the 
loops in PLAHHEB such as THI, FIND, or EXHAUST. He shall call loops 
such as the above "canned" loops since we will often pull them out and 
use them whole when we are in need of a control structure for a 
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routine. The approach of using canned loops is the one used by 

Kleene for constructive realization functions for intuitionistic 
logic. Suppose that we know the following theorei about the 
predicate [REVERSE? x y] which leans that y is the reverse of z. For 
ezanple [reverse? aa aaj and [reverse? [1 2 [3 4J] [[3 4] 2 1]] are 
true. As before • is used to suppress invocations, and a nonad is 
defined to be an atou, a nuaber, [], or [J. The function IDENTITY 
which is used below is the identity function. 


<define th69 <conseguent 

[a b c] 

[reverse? ?a ?fc] 

<cond 

[<hasval? a> 

<cond 

[6<goal I'Caonad? .a» 

; H if a is a nonad then b should be eaual to a” 
<goal ! * <is? .a ?b»] 

[-'"else" 

<goal !»<not I'Caonad? ,a>» 

<goal [reverse? !*Crest ,a> _c]> 

otherwise let c be the reverse of the rest 

of a" 

Cgoal ! • <is? ['{identity .c} !*<1 ,a>] ?b»l>1 
[-."else" <fail>]»> J J 

le would like to find a function reverse such that [reverse? x 
[reverse x]] is always true. The theorea above suggests that we try 
to use linear induction on lists as the control structure. The scheia 
for linear induction applied to the function reverse is: 


Cdefine reverse <function [xl 

I'Ccond 1 J 

[!*<aonad? .z> 

Cteaprog [I ] 

Cassert !<<aonad? «x» 
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£ 


<goal [reverse? .x _T ]> 
s ;*»find a I which is the reverse of the monad 

x and return it as value** 

.Y>] 

-'"else** 

<teaprcg [ T] 

<assert !*<not !*<aonad? .x»> 

<assert [reverse? 

!*<rest .x> 

!*<reverse ! *<rest . x»3> 

<goal [reverse? .x _I]> 

.?>]>» 


The above expression evaluates to the following definition: 


<define reverse <function [x] 

<cond 

[<aonad? .x> 

.x] 

[^«else** 

[{identity <reverse <rest .x») 
<1 .x>]]»> 


7.2.4. Comparison of the Methods 

Superficially considered, there is not much to be said about 
teaching procedures by telling. It is not always clear whether the 
procedure should be taught froa the top down or the primitives should 
be taught first. However, the basics of the method are simple and 
direct. Unfortunately the teacher will not always know the code for 
the procedure which is to be taught. He might be engaged in wishful 
thinking hoping to find a procedure with certain properties. The 
method of canned loops is often applicable to such cases. Trying to 
use the method of canned loops has the problem that the control 
structure must be supposed. Often it is very difficult to guess the 
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kind of control structure which will prove appropriate. Also the 

method of canned loops works on the problea in the abstract as opposed 
to specific exaaples where the identifiers are bound to actual values. 
The advantage of the abstract approach is that if it succeeds then the 
procedure will be known by its construction to have certain 
properties. On the other hand it is often easier to see what to do 
on concrete cases. Often it is easier to show soneone how to do 
something than to tell hia how to do it. Partly this is because the 
descriptive language necessary has not been adeguately developed and 
so *e use "body language". The approach of procedural abstraction is 
to 'oabine together several concrete cases into one sucposed general 
procedure. Properties of the general procedure aust then be 
established by separate arguaent. If the protocols of the examples 
are produced by a goal-oriented language such as PIAHHBB, then there 
will be points along the protocols where certain predicates are known 
to be true. The predicates express the fact that soae goal was 
established as true at that point. Often it is possible to show by 
aatheaatical induction that the corresponding properties in the 
abstracted procedure are always true when the procedure passes through 
the points. In this way a problea solver can have a partial node! of 
his problea solving procedures. The aodels can be expressed naturally 
in PLAHNEB. Also the sethod of procedural abstraction has the 
advantage that the control structure does not have to be supposed in 
advance. Often a problem solver will have the basic problea solving 
ability to solve any one of a certain crass of probleas. 


But he will 
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not know that he has the capability. Briting a procedure which can be 

shown to solve the class enables the problem solver to bootstrap on 
his previous work. Procedural abstraction itself is further evidence 
for the Principle of Procedural Embedding. To implement the principle 
as a research program reguires a high level goal-oriented formalism. 
PL&NNER and some embellishments that we have made to the language are 
first steps toward realizing the Principle of Procedural Embedding. 
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7.3 Current Problems and Future Work 


Currently we have mechanises to handle the following kinds of 
"bugs" or "local changes" in programs: 

HISIDENTXFICATIOH of MOOES: Xf two nodes of a protocol have 
been mistakenly identified as being the same then the mistake can be 
corrected from new protocols which distinguish the nodes. 


VARIABALIZATICH: Procedures can be made more general by 
changing some of their constants into variables. 

PATCHES: Existing routines can sometimes be converted into 
the desired procedure by introducing new intentions into them. The 
patch is produced by the code generated by the new intention as it is 
evaluated by INTENDEB in the environment in which it was placed, of 

course a bug is suspected at the point where an ordinary intention 
cannot be verified. 


He need to find ways to improve the existing mechanisms and to 
find ways to handle other kinds of bugs and local changes. Also 
procedural abstraction must be generalized to accept higher level 

protocols and to make better use of existing procedural knowledge in 
doing the abstraction. 
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8. Hore Comparative Schematclcgy 


Abstract 


Schemata are programs in which some of the function symbols 
are uninterpreted. In this chapter we compare classes of schemata in 
which various kinds cf constraints are imposed on so*e of the function 
symbols. Among the classes of schemata compared are program, 
recursive, backtrack, and parallel. 








8.1. Analytic Theory 


8.1.1 Classes of Scheaata 


8.1.1.1 Recursive Scheaata 
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The following is an informal progress report of soae work that 
I have done with Hike Paterson. John l. white aade important 
suggestions and corrections. The result that recursive scheaata are 
aore powerful than prograa schema was obtained as a tern project in 
the spring of 1969. Rigorous proofs are not given here but just an 
indication of how a proof would go. Prograa schemata are nonrecursive 
procedures that have uninterpreted function symbols and predicate 
symbols. we shall use capital letters to denote uninterpreted 
symbols. we assume that within each computing doaain that there is a 
distinguished element denoted by false and that all other elements of 
the computing doaain are regarded as true in conditional expressions. 
Thus we do not need to distinguish between predicates and other 
functions. Iteration within program schemata is performed by repeat 
loops. Repeats are defined so that (repeat <body>) will repeatedly 
execute <body> until a (return <values>) statement is encountered at 
which point control is transfered out of the smallest enclosing block 
with the indicated values. Blocks can be given names and the function 
(exit <name> <values>) will cause control to leave the named block 
with the appropriate values, it is easy to see that any program 
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schema in the sense of Patterson can be written using BEPEAT and BUT 
with out the use of GO. Writing iterative computations using BEPBAT 
and EXIT has the advantage that all the loops are cf necessity nested. 
8e shall allow schemata to use a finite number of distinguished 
objects which can be tested by the binary predicate IS. For example 
(is x "hello**) is true only if x is the distinguished constant 
"hello". Functions evaluate their arguments from left to right. 

The following is an example of a program schema: 


^ /m y^is^a^a^regis^er cf the program schema g which is 

initialized to the value of the argument x" 

(if (or (P x) (is x "dolly")) then (return y)) 

(x <- (I y)) 

(y <- (B (B y)))) 

The BHF syntax for program schemata is as follows: 



::= <term> 

<blcck> | 

<repeat> | 

<again> | 

<exit> 

(if <tern> then <terms> else <terms>) 
<assignment> | 
false | 

<literal-string> | 


l 


<identifier> J 
<function-call> 
block (block <body>) 

assignment :: = (<identifier> ••<—" <term>) 

repeat (repeat <body>) y 

function-call (<uninterpre-ted-fu.netxon> <arguments>) 

(is <term> <term>) J 

(call 

(<uninterpreted-function> <arguments>) 

<function>) 

again :: ~ (again) | (again <name>) 

exit (exit <name> <terms>) | (return <terms>) 


I 
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body = <nane> <declaration> <teras> | 

<declaration> <teras> 
terns i:= <tera> | <tera> <terns> 
declaration (<identifiers>) 

arguaents = j <teras> 

identifiers | <identifier> <identifiers> 


A recursive scheaa is a prograa scheaa that is allowed 

itself or other recursive scheaata recursively, the following 

exaaple of a recursive scheaa k which is defined by a set of 
eg nations: 


to call 


is an 


<Jc x) * (if (p x) then x 

else (C (k x) (a (B x)))) 

<« y) * (if (p (r y)} then (L y) 

else (C (a (1 yj ) (k (k x)))) 


Por any recursive scheaa defined by a set of r.«.otsive eguaUons we 
can construct an eguivalent recursive scheaa with cnly one eguation 


and one additional arguaent to tell which eguation is being siaulated 
This is possible because we allow recursive scheaata to use a finite 
nuaber of distinguished constants and predicates to test for these 
constants. The following is an exaaple of a recursive scheaa that 
uses the interpreted constant syabols true and false. 


(f x) * (if (P x) 

then 

(if <Q x) 

then true 

else false) 
elseif (f (L x)) 

then true 
else (f (R x))) 
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8. 1.1.1.1 Comparison with Program Schemata 

in fact tte abcve recursive schema is not equivalent to any program 
schema. By equivalent we mean that the two schemata must both fail 
to terminate or both must return the same value for all 
interpretations of the functions P, Q, L# and R. Often we will take 
the set of uninterpreted terms as our domain of interpretation. In 
the above case the domain of interpretation is x (L x) # (R x) # (L (L 
x)), <L (R x)), (R (I x)), etc* The function letters L and R are 

interpreted as 1 and r where: 

jl y) is defined to be the term (L y) 

(r y) is the term {R y) 

Thus (1 (R (t *))) is the term (I <R (1 *))) • Two schemata are 
equivalent if and only if they define the same function on the domain 

of terms. 

Theorem: 

The function f defined above is not equivalent to any program schema. 
Proof: Consider the following class of interpretations £1 n} where n 

is a non-negative integer: 

The domain of interpretation is the set of teras that can be 
constructed from the indeterminate x and the predicate letters L and 
S. The predicate Q is interpreted as a function g with range {true 
false}. The predicate P is interpreted as the function p: 

(h//n x)...}) * true for m = n 


(p (h//C 





INPUT 
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= false otherwise 

where each h//i {"h subscripted by i") is the interpretation for R or 
the interpretation for l and there is at lost one path such that 

(q (h//0...(h//n x)...)) * true 

The douain of (I n} is the set of all terms that can be constructed 


fro* the indeterninate x and the functions L and B. Re are going to 
prove that for any prograa schema P we can find an integer t such that 
P does not define the sa*e function as the recursive schema f on at 
least one member of the class (I n>. In the the interpretation {I 3}, 
we have the following I-R tree (where each node is a ter* in the 

domain of (I 3}): 


{(L (1 x)) 

[(1 (L (L x)))} 

((R (L (L X)))}} 

((8 (I* x)) 

( (L (R (L X)))> 

((R (R (L X)))}}} 

C(R X) 

{(L (B x). 

C(L (L (B x)))} 

((R (1 »B X))}}} 

C(R (B x)J 

((L (R (B x)))} 

((B (B (R x)))}}}} 


The function p is true only 01 the right-most (i.e. bbttcp) nodes and 

g is true on at most one of the right-most (bottos) nodes. Be shall 
define the state of a prograa schema P at a point in its computation 
to be the contents of the registers of P together with the statement 
of P that will be executed next. Two states SI and S2 of P under the 
interpretion I will be said to be EQUIPAIEBT if p executes exactly the 





scheaa. 
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saae sequence of instructions when started froa SI as when started 

froa S2. Be shall define the nuaber of stateaents of a prograa scheaa 
to be the total nuaber of left parentheses in the text of tne prograa 

Suppose we have a prograa scheaa P with s stateaents and k 
registers. In the interpretation {I n}, the prograa scheaa P has at 
aost s*((n*2)-»k) equivalence classes of states where -» is the 
exponential function. (Intuitively the only thing the scheaa can do 
xs tc count down each of its k registers to the bottoa of the L-H tree 
and test each of thea to see if it has reached the bottoa.) However, a 
prograa scheaa needs at least 2-»n steps in order to check if g is true 
on each of the nodes at level n. But after 2-*n steps, P aust be in an 
infinite loop since it will have arrived at two distinct nodes of the 

~4?., fe^e saae equivalence class of states. To see the natter 
soaewhat differently look at the seguence of equivalence classes of 

If the sequence repeats then the prograa scheaa is in an 
infinite loop. But the prograa scheaa aust seek and test all 2-n 

terainal nodes and then halt. Therefore the prograa scheaa needs at 
least 2-*n equivalence classes. 


The Single Instance Theorei: 


1 single recursive scheaatic eguation that defines a function fora f 
can be transforaed into an equivalent prograa scheaa if the fora f 
appears only once in the definition of the function. 
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Proof: 

Define (F-n x) to be F applied n times to some argument x. 
(F-0 x) = x 

(F-(n*1) x) = (F (F-n x)) 

For example (F-1 x) is (F x) and (F-2 x) is (F (F x)). 

Suppose the definition of f is of the form 


(f k) = if {alpha k} 

then {beta k} 

else {gamma (f {delta k}) k} 


where {alpha k} is the expression that is evaluated before the 
recursive call to f, { beta k} is the expression that is evaluated if 
there is no recursive call to f, and {gamma (f {delta k}) k} is the 
value for a recursive call to f. The reader may or may not want to 
examin the following tree which shows f partially expanded: 


(if {alpha {delta-0 k}} 
then 

(beta {delta-0 kJJ 
else 

{gamma 

(if {alpha {delta-1 k}) 
then 

{beta {delta-* 1 k)} 
else 

{gamma 

(if {alpha {delta-*2 k}} 
then 

(beta {delta-»2 k}} 
else 
• • •) 

{delta-* 1 k}}) 

{delta-0 k}}) 





The function f can be re-written as follows: 
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(f k) = (block ((a <- k) n i j) 

• • ,.. n ' and ^ ar€ registers of the program schema f: 

initialized to the value of k" 

(repeat () 

(if {alpha m] then (return)) 

(m <- (delta m})) 

U <- k) 

(n <- {beta m}) 

(repeat ((i <- k) (n <- k)) 

(if {alpha i} 
then 

(exit f n)) 

(i <- {delta i}) 

(repeat ((j <- i) (m <- k)) 

(if {alpha j] then (return)) 

(j <- {delta j}) 

(m <- {delta m])) 

(n <- {gamma n m}))) 


a is 


We would like to repeat the iterative definition of f giving comments. 
<0 An expression that appears within [ and ] is an intention that is 
expected to be true whenever control passes through the expression. 

It is not necessary to understand the intentions in order to 


understand the schema f. In fact many readers might prefer not to read 
the intentions. The intention functions fa, fc, and fd are intended 
to express what goes ct in loops a, c, and d respectively. 


(f k) = (block (j[n <- k) n i j) 

. . . , .• n ' and 3 are registers of the program schema f: a 
initialized to the value of k" 

(repeat a () 

(if {alpha m} then (exit a)) 

(a <- {delta m})) 

[define (fa a) = if {alpha a) then a else {delta a}] 

[(a * (fa k)) ;"It is our intent that a be equal to (fa k) 

this point. It can be shown by induction that this intention is 
always realized."] 

(i <~ k) 

(n <- {beta a]) 


at 
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(repeat c ((i <- k) (n <~ k)) 

(if {alpha i} 
then 

[ (f k) = (fc {delta (fa k)} k) = n] 

(exit f n)) 

[n * (f i) ] 

[define (fd n a j) * if {alpha j) then {gaaaa n a} 

else (fd n {delta a) {delta j} > ] 

[define (fc n i) » if {alpha ij then n else (fc (fd n 


k i) (delta i}) ] 

[n = (fd {beta (fa k)} k i) ] 

(i <- {delta i}) 

(repeat d {(j <- i) (a <- k)) 

(if {alpha j} then (exit d)) 
(j <- {delta j}) 

(a <- {delta a} )) 

(n <- {gaaaa n a}) 

[n = (f a) ])) 


8- 1.1. 1.2 Coapilation 

He can look at prograa scheaata and recursive scheaata as 
autoaata that operate cn the universe of teras as a data space, A 
finite state scheaa autoaaton operates under a finite state control 
structure using a finite nuaber of registers each of which can hold 
one tern. As a priaitive operation the autoaaton is allowed to create 
a tern by applying a function to teras stored in its registers and 
then to store the result back in a register. In addition the 
autoaaton is allowed a finite nuaber of priaitive predicates to test 
the contents of its registers. The class of finite state scheaa 
autoaata is equivalent to the class of prograa scheaata in the obvious 
way. Prograa scheaata can be regarded as being executed by a finite 
state scheaa autoaaton after a suitable coapilation. A pushdown 
scheaa autoaaton is defined to be a finite state scheaa autoaaton with 
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a pushdown stack. In addition a pushdown scheaa automaton is allowed 


a finite nuaber of distinguished constants as teras together with 
predicates that test for the distinguished constants. Re will 
investigate the relationship between these aachiaes and scheaata. The 
appropriate kind of equivalence is one in which side effects are 
allowed. Two scheaata will be said to be side-effect equivalent if 
they are the sane function for all interpretations including those 
which involve side effects. An uninterpreted function aay change the 
definition of any of the unintepreted functions as a side effect of 
being evaluated. For example the schemata jl and j2 below are not 
side-effect equivalent. 


(jit) 3 if (P x) then x 

else (jl (pi (G x) (G x))) 

X 

(pi x y) - X 

(j2 x) « if (p x) then x 

else (j2 (G x)) 

The free interpretations for side effect scheaata are the ones in 
which each uninterpreted function syabol is interpreted is the 
function which evaluates to the list of all the primitive terns that 
have been previously evaluated in the coaputation. For exaaple the 
side-effect protocol tree for j2 is 


if (P x) 

then (x ♦ (P x)) 

else 

if (P (G x)) 

then ((G x) ♦ (P (G x)) (G x) -(p x) i 
else 
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x) -(P x)} 


if {P (G-«2 x)) 

then {(G-»2 x) + (P (G-2 x)) 


(G-.2 x) -<P (G x)) 



else... 


On the other hand the side-effect protocol tree of jl is: 


if (P x) 

then {x ♦ (P x)} 

else 

if (P (G x)) 

then {(G x) +(P (G x)) (G x) (G x) - (P x)} 
else 

if (P (G-»2 x)) 

then {(G-»2 x) +<P <<3--2 x)) <G-2 x) (G-2 x) - (P (G 

x)) (G x) (G x) - (P x)} 

else..• 


Thus jl and j2 are net side-effect equivalent. 


Theorea: Side—effect equivalence is decidable for program 

schemata. 

Proof: The preof is by tree expansion. Two program schemata 

are side effect equivalent if and only if for every execution path of 
one schema there is an execution path for the other with the 
uninterpreted functions called in exactly the same order. Given a 
cycle in one schema it is decidable whether the cycle can be embedded 

in the other. 


Conjecture: side-effect equivalence is decidable by tree 

expansion for recursive schemata. 

If this conjecture is correct then we can attach a post processor to a 
compiler which decides whether or not the compiled code is side-effect 






eguivalent with the source code. 
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The BNF syntax for prograa schema automata is as follows: 


program ::= <ccmmana> 
command ::= <block> | 

<repeat> | 

<again> | 

<exit> | 

<push> I 

<pop> j 

<conditional> | 

<function-call> 

value false j identifier | <literal-string> 

values <value> j <value> <values> 
pop = (pop) J (pop <identifier>) 

. *! 8 (exit <naie> <values>) | (return <values>) 
conditional (iftrue <conmands> else <ccmmands>) j 

(ifempty <ccmmands> else <coaaands>) 
again (again) ) (again <naae>) 

push ::= (push) J (push <value>) 
block (block <body>) 

repeat : := (repeat <body>) 
function-call 

(call 

<nuaber-of-args> 
<uninterpreted-function>) i 

(call 

<nuaber-of-args> 

<uninterpreted-function> 

(<ident£iers>) 

<coaaands>) | 

(call 2 is) 

identifiers | <identifier> <identifiers> 

body <name> <declaration> <coaaands> j 

<declaration> <coaaands> 
declaration (declarers) 

declarers • :* | (<identifier> <value>) <declarers> 

There are a few non-obvious constructs in the above syntax. 

The expression (pop <identifier>) reaoves the top element from the 

stack and aakes it the new value of the identifier. Arguments to 

function are passed on the stack and the results are returned on the 
stack* 
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The Compilation Theorem: 


For every recursive schema there is a side-effect equivalent pushdown 
schema automaton. 


Proof: 

Be shall shorn hov to compile the schema f defined below: 


^ /«y°is a Slew lical^wlich is initialized to (H z) " 

(if (P x) 

then (K x y) 

elseif (and y (P (f x))) 
then (K y x) 
else (G (K y x) y))) 

The compiled form is 

(f x) =• (block ((y false)) 

(push x) 

(call 1 8) 

(pop y) 

(push x) 

(call 1 P) 

(iftrue 

(pop) 

(push x) 

(push y) 

(oall 2 K) 

(return 1) 

else 

(pop) 

(push y) 

(iftrue 

(pop) 

(push x) 

(call 1 f) 

(call 1 p) 

(iftrue 


(pop) 
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else 


(push y) 
(push x) 
(call 2 k) 
(return 1) 

else 

(pop)) 


(push y) 

(posh x) 

(call 2 K) 
(push) 

(push y) 

(call 2 G) 
(return 1)))) 


8.1. 1. 1. 3 Scheaata with Besets 



Tags can be thought cf as identifiers which are bound at each 
activation level. By passing the activation as a paraaeter the level 
of activation can be iaaediately reset by executing a transfer of 
control through the activation, in order to obtain an equivalent 
machine, we can extend the instructions of the push down scheaa 
autoBaton by allowing thea tc store a pointer to the top element of 
the stack into one of the registers. The resulting class of aachines 
is called the reset push down scheaa autoaata. if the stack is ever 
popped back past a location that is pointed to by a register then the 
autoaaton halts with an error. Be found discussions with Hike 
Fischer helpful in analyzing scheaata with resets. 

The Beset Theorem: 


The class of reset push down scheaa autoaata is equivalent to the 
class of ordinary push down schema autoaata. 

Be shall show how we can translate 


a reset push down scheaa 
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into an equivalent ordinary push down schema. An ordinary function 

call (f x//1 ... x//n) will be translated into (call (f x//1 ... x//n) 
Cy y//1 ... y//1) body) where we will explain the body below. The 
idea is that if the function f wants to execute a non local transfer 
of control through argument x//i we can simulate this by returning the 
corresponding y//i as "exit" or "again" depending on whether the block 
x//i is to be exited or reiterated respectivey. Then the procedure 
which makes the call to f can test the values of the y//i and take the 
appropriate action depending how the name was generated. Consider the 

following example: 


(try x) = (repeat tl () 

(if (Q X) 

then 

(x <- (F x)) 
elseif (P x) 
then 

(x <- (harder (F x) tl)) 

;"the name tl is an identifier" 

(if (not x) 

then (return false)) 
else (return false))) 

(harder xl tag) * (repeat () 

(if (Q xl) 

then 

(x <- (F xl) ) ;"set the global x to (F xl) ■ 

(again tag) ;"reiterate the repeat loop named tag" 

elseif (P x) 
then 

(xl <- (harder (F xl) tag)) 

(if (not xl) 

then (return false)) 
else (return false)) 

He can rewrite try and harder as try* and harder* respectively so 




INPUT 





TREE WHICH IS SEARCHED BY G 

(In the order in which the nodes ore 
numbered ) 








(try* x) 


(harder 


"exit") 
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= (repeat tl () 

(if (Q x) 
then 

(x <- (P x))) 
elseif (P x) 

1 (x <- (call (harder* (f x) tl) (y yl y2) 

(if 

(is y2 "again") 

then 

(again tl) 

elseif 

(is y2 "exit") 

then 

(exit tl) 
else y))) 

(if (net x) 

then (return false)) 

else (return false))) 

• xl tag) * (repeat () 

(if (Q xl) 
then 

(x <- (F xl)) . 

(exit harder* false false "again") 

{"reiterate the loop naned tag" 

elseif (P xl) 
then 

(xl <- (call 

(harder (F xl) tag) 

(y yi y2) 

(if 

(is y2 "exit") 

then 

(exit harder* false false 

piqpif 

(is y2 "again") 

then 

(exit harder* false false 
else y))) 

(if (cot xl) 

then (return false)) 
else (return false))) 


"again") 
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8 . 1 . 1 . 1.4 Decompilation 


The Decompilation Theorem: 


For every push down schema automaton we can effectively construct a 
side-effect equivalent recursive schema. 


Proof: 


The only difficult constructs to translate are the push and 
pop commands. He shall translate {push <value>) as «function> 
<value> tags false) where <functi,on> is a unique function name 
distinct from all others. The function is defined to be have two 
arguments x and y and have a body which is the code that fellows the 
push command which is teing translated. The command (pop, is 

translated as (GO <tag>) <tag>: where <tag> is a unique tag distinct 
from all others, whereas (pop <identifier>) is translated as 

(<identa.fi er> x) (GO <tag>, <tag>:. The idea is that there must 

be a tag for every instance of a call to pop so that control can get 
back to the proper place. 


Consider the following push down schema automaton 


(f y) * 


(block (, 
(push) 

(call 1 g) 

(return 1)) 


19 y ’ * ipu!hj“ <> 

(call 1 p, 
(iftrue 

(pop) 
(posh) 
(call 1 


Q) 
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(iftrue 

(POP) 

(repeat () 

(ifeapty 

(terminate "t")) 

(pop))) 


else 

(pop) 

(pop) 

(ifeapty 

(terainate false)) 

else 

(call 1 R) 

else 


(pop) 

(push) 

(call 1 L))) 

The schema f can be decompiled as follows: 


,£ *> ' < block 'US',‘1,1,. false false false «f>> 

(f0 x al ( »2 j3 t «« t j5 t5 « t e.||H t -f (giyat 0 

(X <- <P X)) 

(if 

x 

then 

(go nl) 

11 : 

rf2 x tl t2 t3 t4 t5 t6 false) 

(x <- (Q x)) 

(if 

x 

then 

(go n2) 

t2: 

(repeat () 

(if 

empty 

then 

(exit outer H")) 

(go n3) 

t3: 

) 

else 


(go n4) 
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t4: 
t5: 


(go o5) 


(if 


then 


eapty 

(exit outer false) 
(x <- (H x)))) 


16 


(go n6)) 


(f3 x tl t2 t3 t4 t5 t6 false) 
(x <- (L x))) 


(f 1 x nl n2 n3 n4 n5 n6 eaptr) 

(if 1 


(block () 


then 


(go nl) 
(go n2))) 


(f2 * nl £2 n3 n4 n5 n6 eapty) * (block () 

x 

then 

(go n3) 


(go n4))) 

(f3 x nl n2 a3 n4 n5 n6 eapty) = (block 

(x <- (lx)) 1 

(fO x nl n2 n3 n4 n5 n6 eapty)) 
8.1.1.1.5 Priaitive Recursive Scheaata 


0 


Definition a recursive scheaa f will be said to be PRIMITIVE 
RECURSIVE in the the uninterpreted function syabols u if f can be 
defined recursively as (f x//\ ... x//n) = phi[x//1 ... x//n] where 
each instance (f t//1 ... t//n) of a call to f within phi[x//1 ... 
x//n ] has t//1 of the fora (h x//l) where h is in the set U and the 
only other functions in the definition are either uninterpreted or a: 
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themselves primitive recursive in U. 

For example the following schema is primitive recursive in {L 


B). 


{f X) = if {P x) 

then (Q x) 

else (C (f (I x)) (f (B x))) 

The following schema is not primitve recursive in {S}; 

(ackerman w x y) * 

(if (Z x) 

then 

if (Z *.) 

then y 
elseif (0 w) 

then (ZERO) 
else (ONE) 
elseif (Z w) 
then 

(P 

(ackerman (ZEBC) (S x 1) y) 
(OSE)) 

(ackerman 

(S w 1) 

(ackerman w (S x 1) y) 

Y>) 


else 
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8.1.1.2 Schemata with Counters 


He would like to present another example of a function that 

can be computed by a recursive schema but not by any program schema. 

Define (F-n x) as in the proof of the Single Instance Theorem. Thus 

( x) — (f (F-*n x)} • Suppose that we successively compote (F 

x) t (F (F x)), etc. As we successively compute the guantity (F-*i x) 

for some integer i we shall keep a running count of the number of 

times that (P |F-«j x)) has been true for j less than i, minus the 

number of times that (P (F-j x> > has been false for j less than i. if 

this count ever goes negative then we shall return false as the value 

of the function (zero x) , otherwise the function (zero x) will run 
forever. 

The Counting Conjecture for Program Schemata 

The recursive schema * zero' defined below is not schematically 
equivalent to any program schema. 


(zero x) * (repeat a () 

(if <P x) 

then 

(x <- (positive (F x))) 

(if x 

then 

(again a}) 
else 

(return false) 

else 

(return false)} 

end 

The schema 'zero' uses the schema 'positive' to keep track of the 
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count by the depth of recursion of the schema ’positive*. 


(positive x) = (r||eat a^ () 

then 

{x <- (positive (F x))) 
(if x 

then 

(again a)) 
else 

(return false) 

else 

(return (F x))) 

end 


Using the technique of loop elimination we can convert the above 
functions into purely recursive schemata, lie shall define a schema 
zero 1 which is equivalent to zero and a schema positive 1 which is 
equivalent to positive. 


(zerol x) = (if (P x) 

t hen 

(if (pcsitivel (F x))) 
then 

(zerol (positive 1 (F x))) 
else 

false) 

else 

false) 


(positivel x) = 

(if (P x) 

then 

(if (pcsitivel (F x)) 
then 

(positivel (positivel (F x))) 
else 

false) 

else 

<* *)) 

The protocol tree for the schema zero is 
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(if (P (F-*0 x)) 
then 

(it (P (P-.1 x)) 
then 

(if (P (F-»2 x)) 
then 
• • • 
else 

(if (P (F-»3 x}) 
then 


(if (P (f-»4 x)) 
then 


• • • 


else 

false))) 


(if (P (F-.2 x)) 
then 

(if (P (F-»3 x)) 
then 


(if (P (F-»4 x)) 
then 
else 

else 


false)) 

else 

false) 

However a progran schena can solve the 


problen if ve give it 


a 


counter. He postulate the functions and zero? which 

respectively add, subtract, and test for zero. The following prograw 
schena is scheaatically eguivalent the the function zero: 


(zerol x) * (block (n) (return (zero2 x))) 

(zero2 x) * (repeat () 

(if (P x) 
then 

(x <- (F x)) 

(n <- n ♦ 1) 

else 

(if (zero? n) then (return false)) 
(n <- n-1))) 
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By allowing recursive schemata to use a counter# we can construct a 
function ’reczero’ that is not equivalent to any ordinary recursive 
schema, the function reczero counts the number of nodes along the 
bottom of the L-R tree that have the property P minus the ones that do 
not have the property P. The function returns the value false if the 
count ever goes negative. Re assume that arguments are evaluated from 

left to right. 


The Counting Conjecture.for Recursive Schemata: 


The schema (with counters) reczero defined below is not equivalent to 
any ordinary recursive schema. 


(reczero x) * (block (n) (return (reczerol x))) 

(reczero! x) * 

' (if' (BOTTOH? x) 

then 

(if (P x) 
then 

(n <- n+1) 
true 
qJLSC! 

(if (zero? n) then (return false)) 

(n <- n-1) 
true) 

else 

(if (net (reczerol (L x) )) then (return false)) 

(if (not (reczerol (R x))) then (return false)) 
(return true)) 

The reason that reczero is not equivalent to any recursive schema is 
very similar to the reason that no recursive schema can search the 

i 

branches of the L-B tree in parallel. If a recursive schema is 
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equivalent to reczero then it is constrained to search the tree in 

essentially the same order that reczero searches the tree. Otherwise 
it could be made to fall into an infinite loop on an interpretation 
where reczero converges. Re conjecture that constrained in this 
fashion a recursive schema has only a finite number of states in which 
to try to keep the count. The recursive schema cannot succeed for. the 
same reason that we conjecture that no program schema is equivalent to 
the function zero defined above. 

Conjecture: the following function is not 
schematically equivalent to any purely schematic recursive system of 
equations. The function even is supposed to test whether the number 
of bottom nodes of a L-R tree that are true for the predicate p is the 
same as the number that are false for the predicate p. The schema 
'even* differs from the schema 'reczero* in the crucial respect that 
•even* always looks at all the bottom nodes before it comes to any 
conclusions. Thus a recursive schema that tries to imitate the 
schema even has a lot more room in which to maneuver. He conjecture 
that no recursive schema can have enough internal states to be 
equivalent to the function even defined below. 

(even x) = (block (n) 

(evenl x) 1 ' 

(return (zero? n ))) 

s' 

(evenl x) = 

(if (BOTTOM? x) 
then 

(if (P x) 
then 

(n <- n+1) 
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x) 

else 

(n <- n-1) 

x) 

else 

(even (L x)) 

(even (R x))) 





8. 1. 1.3 


Parallel Schemata 
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Be introduce the delimiters "1(" and «)« to delimit quantities 
that are to be computed in parallel. Bhenever a process executes an 
expression like |(x) it divides into two processes. One process 
executes x and the other attempts to continue normal execution. For 
example in the expression | (2+3) * (4*5) , the product 4*5 is computed in 
parallel with the sum 2*3. Thus the expression "(block ((return x) 
(return y))" is defined to be the value of x or y depending on which 
evaluates first in seme particular but unspecified parallel 
computation. Processes can coordinate their actions through locks. 
Any expression x can be locked by (lock x) provided that the 
expression is not already locked. If x is already locked then any 
process which executes (lock x) will be blocked until x is unlocked by 
the primitive (unlock x). However a process can execute (locked? x) 
which will return true is x is locked but will lock x if it is 
unlocked. The kind of call delimited by *1 (•* and M ) " can be 
implemented using the following primitives: 

(create f) will create a new processwhich will begin execution 
with a call to f and will return the name of the created process as 
the value of the function create. 

(resume (p send-args) f) will suspend execution of the process 
that calls resume and will resume execution of the process named p 
with arguments send-args. If the process p is already running then 
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the process which called resuume will fce blocked until f becomes 
suspended. If the process which called resume is itself ever resumed 

then it will invoke f with the arguments received. 

(fork (p send-args)) will resume exeuction of the process p 
with arguments send—args and in parallel return the name of the 
process forked as the value of the function fork. 

(interrupt p x) will interrupt the execution of the process p 

and then begin execution of x IN THE PBCCESS p. 

(step p) will step the process p through one step. 

By adding the above primitives we obtain the class of Parallel 
Schemata. It is our thesis that the class of Parallel Schemata is in 
fact UNIVERSAL for the class of all effective schemata. By this we 
mean that for any effective schema there is a timing side-effect 
eguivalent parallel schema. Two automat a and b will be said to be 
timing side—effect equivalent if for every computation of a there is a 
side-effect equivalent computation of b where the timings of the 
control primitives of fc are allowed to be arbitrarily adjusted and 

vice-versa. 

Ke define the following function using parallel processings 

(f x) = (if (P x) 

then x 
else 

begin 

| (return (f (L x))) 

(return (f (B x))) 

end) 
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The above function is determinate {i.e. halts and has the sane value 

independent of the relative speed at which the sub-processes run} on 

infinite binary trees in which the predicate P is true cn only cne 
node. 

The Parallel Evaluation Theorem: 

The function f defined is net equivalent to any recursive schema. 
Proof: Suppose a set of recursive equations {f//0, f//1, ..., f//n} 

is schematically equivalent to f with f//0 equivalent to f. That is 
for all interpretations of the uninterpreted function symbols, the 
schemata f and f//0 are the same function. Suppose that we start up 
f//0 on input x and make the predicate F false for every node to which 
it is applied as f//0 computes along. If the computation converges 
then f//0 does not lcck at some node which is a contradiction of the 
supposition that f//0 is eguivalant to f. Therefore the computation 
runs forever and the seguence of statements through which the control 
passes is ultimately periodic. Consider the sequence of arguments to 
one of the functions (call it f//i for M f subscripted by i M ) as the 
control passes through one cycle. Suppose that f//i is a function of 
j arguments: a//1,..,,a//j. The arguments with which f//i will be 
called after the control has passed through one cycle are terms 
definable from a//1,.. .,a//j. Let us call then a//1-»1,...,a//j-»1. 

The situation can be diagramted as follows: 


(f//i a//1,...,a//j); the beginning of the cycle in the 
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control structure 

{f//i a//1-*1, ... ,a//j-*1) ; «e pass throuqh the sa»e point of 

the cycle in the control structure 

If none of a//1-*1 # .,, ,.a//j-«1) is the same as one of a//1,... ,a//1 
then we are done since the arguments of the recursive eguations are 
tracing j paths down an expontentially growing tree which means that 
some node is not looked at. If we set the interpretation so that P is 
true for the node then we have a contradiction. We conclude that the 
fact that one of a//1-1, ...,a//j-1 might be same as one of 
a//l # a//j is a nuisance. Let us call the arguments to f//i after 
we have gone through the cycle k tines a//1-*k,.. .a//j-»k. Observe that 
if we go through the cycle jl times then there will be some i such 
that i is less than j! and a//1-»i*...#a//j-'i has fh© property that it 
is an epicycle. By this we mean that some a//g^i is the same as one 
of a//1 # ...#a//j if and only if it is the same as a//q. All such a//g 
do net contribute to the number of nodes examined since they axe 
repeats of nodes previously examined in exactly the sane way* The 
situation can be diagrammed as follows: 



(f//i J 


e 

(f//i a//1-1, .,a//j-»1) 



(f//i a//1~>k, 
the control structure 
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• •#a//j-»k); the beginning of the epicycle in 


(f//i a//1-» (2*k) , 
point in the epicycle 


• • • »a//j-* (2*k)) ; we pass through the same 


Threrefore we can coaplete our proof by applying tc epicycles the 
above argument that we used for cycles. 
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8.1.1.4 Locative Scheiata 


The Locative Theorem 

« 

If locations of identifiers are an allowed data type, then the control 
structure of recursive schemata can compute any partial recursive 

function. 

Proof: 

Let {at x) denote the location of the identifier x. 

Furthermore suppose that we have a function in of one argument which 
will return the contents of its argument. The proof will be phrased 
in terms of pushdown schema machines. He can define a counter using a 

register as fellows: 


(block ((c 1 false)) 

(initialize-ccunterl) * (block ((w false)) 

(push (at w)1 
(pop cl)) 

(count-upl) * (block ((y false)) 

(push cl) 

(pop y) 

(push (at y)) 

(pop cl)) 

(count-downl) * (block () 

(push cl) 

(call 1 in) 

(pop cl)) 

(zero-test 1) * (block () 

(push cl) 

(call 1 in) 

(iftrue (push "t")) else (push false)))) 
Marvin Minsky proved that two counters are universal. Q.E.D. 
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8.1.1.5 Schemata with Selectors and Beplacenent 

Another way in which we can proceed is to impose data types on 
the computing domain, storage off the stack can be established by 
postulating a constructor c and selectors si and s2 such that for all 
x and y in the computing domain we haves 

(si (c x y)) * X 
(s2 (c x y)) * y 

in the domain of interpretation. Classically we would postulate that 

every call to the constructor aust return a new element of the 
computing domain. 
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8.1.1.6 Schemata with Free Variables 


(c i y) * (block (z) . 

(z <- (si free-storage-list)) 

(free-storage-list <- (s2 free-storage-list)) 

;"free-storage—1ist is free in c” 

(return (CCNSTBOCTOH x y z)) 


The point is that in general (c x y) will not be the same as (c x y) 
because of use of assignment on the free varialbe free-storage-list. 
Other than in this fairly trivial way, schemata do not add any power 

to recursive schemata. 
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8.1. 1.7 Schemata with Iquality 


Schemata with equality are allowed to make use of a special 
predicate (= x y) whose interpretation is that x and y are the same 
element of the domain cf interpretation. Universal domains of 
interpretation for schemata with equality are the Herbrand universe 
with a congruence relation theta such that: 


1: theta is an equivalence relation 


2: if x/1 theta y/1< .... and x/n theta v/n then for earh 
unrnterpreted function f and predicate p: h 

(f x/1... x/n) theta (f y/1 ... y/n) and 

(p x/1 ... x/n) if an only if (p y/i ... y/n ) 


In other words the elements of the domain of interpretation 
equivalence classes of theta. 


are the 
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8. 1.1. 8 Hierarchical Backtrack Schemata 

PLANNEE uses a acre powerful control structure than that of 
the recursive function call. A BACKTRACK CONTROL STRUCTURE is used 
which means that at any point a process can fail which will cause it 
to back up to some previous state and then continue. The priaitive 
function (FAIL) will generate a simple failure. The primitive 
function (FAILPGINT try lose) will evaluate the expression try. If 
the evaluation succeeds then the value of the function FAI1P0INT is 
the value of try. Otherwise the value of the function FAILPOINT is 
the value of lose. For example the value of 

<♦ 

(failpcint (x <- 2) (x <- 3)) 

(if x=2 then (fail) else 4)) 

is 7 since x first gets the value 2 but then is given the value 3 when 
a failure backs up to the function FAILPOINT. 

8.1.1.8. 1 Comparison with Recursive Schemata 

He shall give an exaaple tc show that backtrack control 
structure is more powerful than recursive control structure. 

Backtrack Schemata Are Hore Powerful than Recursive Schesata 
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The backtrack schema g defined below is net equivalent to any 

recursive schema, what the schema g does is to search the following 
iree for x looking for a node on which P is trues 


(1-1 X) 

(L-2 x) 

(L-3 X) 

(R-1 (1-2 x)) 

(L-4 x) 

(INI (1-4 x)) 

(8-1 (L-»1 xj) 

(IN 2 (L-1 x))) 

(R-1 x) 

(8-2 X) 

(8-3 x) 


We have shown in the section on parallel schemata that no recursive 
schema can do the search. 


(g x) = <h (f x)) 

(h z) » (if z 

then 

"true* 

else 

(fail)) 


(f x) = 

(fail? 

(P x) 

(block 


; M y is a new local" 

(y <- x) 

(8 

(f (I x)) 

(if (P 1 ) 

then true 

else (y <- (R y) false))))) 


The reason that we make the function k defined below into a senaratA 
function is so that BOTH arguments will be evaluated. separate 
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(k s t) = if s 

then 

"true” 
else t 

Proof: The proof is similar to the proof of the parallel 

evaluation theorem. Suppose a set of recursive equations {f//Q, f//1, 
f//n} is schematicaly equivalent to f with f//0 equivalent to f. 
Suppose that we start up i//0 cn input x and make the prdicate p true 
for every node to which it is applied as f//0 computes along. If the 
computation convereges then f//0 does net lock at some node which is a 
contradiction cf the supposition that f//0 is equivalent to f. 
Therefore the computation runs forever and the seguence of statements 
therough which the control passes is ultimately periodic. 

8.1.1.8.2 Comparison with Hultiprocess Schemata 

The method by which multiprocess schemata can simulate 
hierachical backtrack schemata is messy but straight forward. 

Hultiprocess schemata are more powerful than backtrack 
schemata. One example which may show this is the one used to show 
that parallel schemata are more powerful than recursive schemata. 
Unfortunately we have not yet been able to prove that backtrack 
schemata cannot search the full L~8 tree. So we shall resort to brute 

force techniques. 

He would like to define the P-length of an expression x as the 
number of times which D can be applied to x before (P x) is true. 



PROGRAM SCHEMATA 



k REGISTERS EACH OF WHICH CAN HOLD 
AN INTEGER UP TO n 



s STATEMENTS 


HAS AT MOST sn k STATES 
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Thus (P-length x) = (if (P x) then 0 else 1* (P-length (D x))) No* we 
would like to define a schema expt such that 

(expt x y) * (I'-(2-(P-length x)) y) 

Suppose that (P-length x) = 2. Then (expt x y) = (I-* (2-*2) y) = (I-»4 
y) * (I (I (I (I y)))). 

(expt x y) * (if (P x) 

then 

(I y) 

q]^S6 

(expt (D x) y (expt (D x) y))) 

Now we claim that there is no program scheta which is 
equivalent to expt. Suppose to the contrary that there is a program 
schema with k registers and s statements which is equivalent to expt. 
Such a program schema has at most only s * k-»(P—length x) equivalence 
classes of states. Thus if it runs for more than s * k-»(P-length x) 
steps it must be in a loop. Therefore it cannot possibly produce the 
output (I-'(2-* (P-length x)) y) since s * k-» (P-length x) is less than 
2-» (P-length x) for large values of (P-length x). This is a 
contradiction. 

In an exactly analogous fashion we can prove that there is no 
recursive schema expt2 such that 

(expt2 x y) = (I-« (2-* (2-» (P-length x))) y) 

Suppose that there is a recursive schema with k registers and s 
statements which is equivalent to expt2. Such a recursive schema has 
at most only 




RECURSIVE SCHEMATA 


STACK OF REGISTERS 


k REGISTERS 

*1 

• I 
I I 
I I 


EACH REGISTER CAN HOLD AN 
INTEGER UP TO n. 


s STATEMENTS 


HAS AT MOST sn k n 8 " k STATES 
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j = s * (P-length x) -«k * (P-length x)-*(s * (P-length x)-»k) 
equivalence classes cf states. The same state counting argument shows 
the contradiction. The above argument has been independently 
discovered by Bobin Milner. 

Theorem: Multiprocess schemata are more powerful than backtrack 

schemata 

Proof: Me will apply cur brute force technique. There is no 

backtrack schema expt3 such that 

(expt3 x y) = (I-» (2-* (2-« (2-< (P-length x) ))) y) 

Suppose that there is a backtrack schema with k registers and s 
statements which is equivalent to expt3. Let J be as defined above. 
The recursive schema has at most J-'J equivalence classes of states. 
Thus if it runs for more than J-*J steps it must be in a loop. 

Therefore it cannot possibly produce the output (I-. (2-^2- (P-length 
x)) y) since J-J is less than 2-2-*2- (P-length x) for large values of 
(P-length x) . This is a contradiction. 





BACKTRACK SCHEMATA 

STACK OF REGISTERS 


k REGISTERS 
r 2 R k 


EACH REGISTER CAN HOLD AN 
INTEGER UP TO n 


s STATEMENTS 


HAS AT MOST J J STATES WHERE 

J * s n ^ n sn * 
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8.2. Synthetic theory 


8.2.1 Realizations 

8.2.1.1 Realizations for the Quantificational Calculus 

We would like to show how we can use schemata to express 
procedurally the aeaning of certain constructive logically valid 
sentences in the predicate calculus, classically* intuitionistic 
logic has been used to prove constructive sentences. However, the 
connection between this language and push down schema automata is 
somewhat indirect. Be need to define the notion of a schema g 
realizing a formula phi. Roughly speaking g realizes phi if it tells 
how to compute the value of phi from the subformulas of phi depending 
on the logical connectives of phi. Kleene's notion of "g realizes 
phi" is defined by induction cn the structure of phi: 

For {terms}. g realizes phi where phi is a term if g is true 
if and only if phi is true. For example (P (F w) z) realizes (P (F w) 

z) . 

For {and...}, g realizes phi = (and theta psi) if (g 0) 
realizes theta and (g 1) realizes psi. Rote that g really is two 
functions in disguise. 

For {or...}, g realizes phi = (or theta psi) if whenever (g 0) 
is false then (g 1) realizes psi and whenever (g Q) is not false then 
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(g 1) realizes theta. 

For {implies...} . g realizes phi = (inplies theta psi) if 
whenever h realizes theta then (g h) realizes psi. 

For {not...}, g realizes phi = (not theta) if for no h is it 
the case that (g h) realizes theta. 

For {all.,.}, g realizes phi = (all x [theta x]) if for all x 
it is the case that (g x) realizes [theta x]. 

For {some...}, g realizes phi = (some x [theta x ]) if (g i) 
realizes [theta (g 0) J. 


Consider the following formula which we shall call phi: 


(implies 

(some x 

(implies (A x) 
(inplies (all x (Ax)) 


(B x)>) 

(some x (B x)))) 


»e claim the function g defined below realizes phi. 


g = (lambda h (lambda k (lambda s 

(if s - 0 

tfcen (h 0) 

else ((h 1) (k (h 0))))))) 


(9 h) 

realizes phi 


Uniin irn oj Wiry > > 11 10 i,u 

suppose that k realizes (all x (A x)l 
(k (h C)) realizes (A (h 0)) 

((h 1) (k (h 0))) realizes (B (h 0)) 

(((g h) k) 1) realizes (B (((g h) k) on 
(<g h) k) realizes (some x (B x)) 
realizes (implies (all x (Ax)) (some x (B x))) 
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He are interested in knowing when a formula can be realized 
constructively. 

Realization Theorem for Recursive Schemata *ith Functional Arguments. 

If phi is prcveable in intuitionistic logic# then phi is 
realizable by a recursive schema with functional arguments. The 
Realization Theorem represents one approach toward a constructive 
theory of computation. From a description of the kind of object that 
we would like to have given the description of certain other objects 
as input# we derive a program for computing our goal. Actually we 
shall prove that for intuitionistic logic the realization function can 
be made primitive recursive. The proof is a slight modification of 
the standard proof for the integers. It is a warm up for the 
analogous proof for the deductive system of PLANNEE. However, in 
PLANNER we require the full power of the recursive functions for our 

constructive realizations# 

Proof: The following proof is by induction on the structure of 
intuitionistic proofs using natural deduction. It goes by 
straightforwardly winding and unwinding of definitions. With a little 
work we could get PLANNER to create the proof. 

{and introduction! . 

theta realized by say g 

psi realized by say h 

(and theta psi) realized by (lambda s (if (s = 0) then g else 

h>) 
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{and elimination} 

(and theta psi) realized by say g 

theta realized by (g 0) 
psi realized by (g 1) 

{or intro} 

psi realized by say g 


9 )) 

g)) 


(or theta psi) realized by (la.bda t (if t>0 then false else 
(or psi theta) realized by (laabda t (if t=0 then true else 


{or elim} 


(or 


theta psi) realized by say g 

theta hypothesis; suppose that theta 


is realized by h 


„ eventually deduce say omega which is realized bv 

for some recursive m using the inductive hypothesis eaXiZea Dy 

psi hypothesis; suppose the psi is realized by k 


(m h) 


eventually deduce omega which is realized bv (1 ki fnr 
some recursive 1 using the inductive hypothesis eaX1Zea by K) for 


D)) 


omega which is realized by (if (g 0) then (m (g 1)) else 


a (g 


{implies intro} 


omega hypothesis; suppose omega is realized by h 


9 

eventually deduce say psi which is realized bv fa hi 
for some recursive g using the inductive hypothesis. y 9 

(implies omega psi) realized by (lambda h (g h)) 

{implies elim} 

(implies omega psi) realized by say g 
omega realized by say h 

psi realised by (g h) 
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{neg intro) 


omega hypothesis; suppose that omega is realized by h 


eventually deduce say (not psi) which is realized by 

(g h) for some recursive g using the inductive hypothesis 
w eventually deduce psi which is realized by (k h) tor 

some recursive k using the inductive hypothesis. 

7;; omega) which is realized by any function since it is 
impossible fo? both (not psi) to be realized by (g h) and for psi to 
be realized by (k h) . 

{all intro) 


|eventually deduce say [omega x] which is realized by 
(g x) for some recursive g using the inductive hypothesis 

(all x [omega x)) realized by (lambda x (g x)) 

{all x j- oae ga x)) realized by say g 

[omega t) for some term t; realized by (g t) 

{exist ^ ] is realized by say g where t is a term 

(exist x .[ omega x)) is realized by (lambda s (if (s = 0) then 
t else g)) 

(exist x [onega x]) realized by say g 

x| [omega x) realized by (g 1) 


(eventually deduce say psy which does not contain x 
free; psy is realized by (m (g 0) (g 1)) for some recursive m using 

the inductive hypothesis. 
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psy 


Thus we have completed the inductive proof. 


Intuitionistic Implementation Theorem 

For every recursive schema P, we can effectively find a first 
order formula [theta x y] such that P is total if and only if (all x 
(some y [theta x y ])) is proveable in intuitionistic logic. 
Furthermore, the program P on input x converges to the value y if and 
only if [theta x y] is proveable in intuitionistic logic. we assume 
that all uninterpreted function symbols in schemata are total. 

We shall give an example of how to construct the formula theta 
for the following program which is due to Paterson: 

(g x) = (if (T (F x)) 

then <h x (F x)) 
else x) 

(h x y)= 

(if (T (F (F y))) 
then x 

elseif (T (F x)) 

then (h (F x) (F (F y))) 
else (g (F x ))) 

we can obtain the formula that we reguire by doing a straight forward 
translation of the recursive equations into the guantificational 
calculus. These formulas are similar in intent to those of Manna, 
however we need use only intuitionistic logic to obtain the result we 
reguixe. The formula [theta x y] to be constructed is the 
conjunction of the following three formulas where "iff" is an 
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abbreviation for "if and only if": 


(iff 


(PG x y) 

(or 

(and (1 (F x)} (PH x (F x) y)) 
(and (not (T (F x)) (y = x))))) 


(all 


x 1 x2 y (iff 
(PH x 1 x2 y) 

(or 

(and 

(and 


(and 


(T (F (F x2))) (y = xl) ) 

(not (T (F (F x2)))) 

(T (F xl)) 

(PH (F xl) (F (F x2) ) y)) 

(not (1 (F (F x2)) ) ) 

(not (T (F xl))) 

(PG (F Xl) y))))) 


(all x (or (T x) (not (T x)))) 

The last statement comes from the fact that we are assuming that all 
uninterpreted functions are total. The schema g is indeed total. 

Even after adding selectors and constructors the realization 
theorem can still be proved in the standard way. He introduce the 
predicate atom which tests to see if its argument is atomic and thus 
cannot be broken down using the selectors. The following rule is 
added to intuitionistic logic: 


(all x (implies (atom x) [theta x])) realized by say g 

x,y|[theta x] hypothesis; suppose [theta x] is 

realized by (m x) , , . , . , . 

|[theta y] hypothesis; [theta y] is realized by 

y) 

i 


(m 






(h a x y) 


I 

1 eventually deduce [theta (c x 
using the inductive hypothesis 


y) ] realized by say 


(all x [theta x]} realized by 
(k x) = (if (atom x) 


then (g x) 

else (h k (si z) (s2 z))) 


Sometimes an increase in efficiency can be obtained from 
replacement operators xl and r2 such that 


z) 

Z) 


if * - (si z) and y 
v, and (s2 z) = y 

if X a (Si z) and y 
x f and (s 2 z) = v. 


(s2 z) then after 
(s2 z) then after 


(rl z w) we have (si 
(r2 z w) we have (si 


»e shall call schemata that allow the use of selectors and replacement 

operators list structure schemata. Two schemata will said to be 

equivalent as list structure schemata if for all interpretations of 

the uninterpreted function symbols they are the same function. For 

schemata that dc not explicitly contain si, s2, rl, or r2 list 

structure equivalence is the same as side-effect equivalence, we have 

shown above how to construct a universe of terms so that two schemata 

are side-effect equivalent iff they are equivalent over the domain of 

terms. it is impossible to use the universe of terns as a universal 

domain of interpretation when the use of replacement operators is 
allowed. 
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8.3. Current Problems and Future Work 


How can we characterize more precisely the difference between 
functions that need to use a recursive or parallel control structure 
as opposed to those that only need a simple iterative proqram 
structure? The problem of deciding whether any given recursive 
schema can be rewritten as a program schema is of course undecidaDle. 
we would like to find general criteria of independent interest which 
would be sufficient to guarantee that a recursive schema could not be 

rewritten as a program schema# 

There is general agreement that the theory of computation is 
currently not in good shape# The three major areas (automata theory r 
recursive function theory, and special case hacks) are not applicable 
to practical programs. We can contrast our plight with the situation 
in applied physics. An applied physicist finds that it is essential 
to understand fundamental physical laws both in designing his 
experiments and in interpreting their results. Ho such fundamental 
laws and principles are kncwn in programming. Recursive function 
theory sets the very outer limits of what is possible. Few theories 
are more elegant. However, the fact that classical recursive function 
theory deals with the indices of the partial recursive functions and 
not with the meaning of the programs has been a fundamental 
limitiation on the applicability of the theory. For example the 
recursion theorem says that fixed points exist for any acceptable 
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Goedel numbering. Almost all the classical theorems of recursive 

function theory can be derived using only the Godel axioms for indices 

of partial recursive functions, siailarly, the complexity theory of 

the recursive functions can be derived from Blum»s axioms for indices. 

Automata theorists have been able to discover some of the structure of 

various limited classes of automata such as finite state machines, 

push down machines, and space and time bounded machines. However, 

since the theory developed has been mostly concerned with closure and 

complexity properties of the special machines considered as acceptors, 

it has had limited applicability to real computer programs. Host 

programs are not structured in the way required to fall into one of 

the special classes of machines, some theorists hope that by studying 

enough examples of very narrow domains of algorithms where we have a 

lot of domain dependent knowledge that we can induct a theory of 

computation in a Baconian fashion. Deep studies have been made on 

questions such as how fast integers can be multiplied and how fast 

matrices can be multiplied, studies in the theory of searching and 

sorting appear to be mere relevant for constructing a unified theory 

of computation since they are concerned with basic computational 
abilities. 

Studying the properties of programs schematically offers 
several advantages. Schemata can be programmed in a realistic 
fashion. They mirror the structure of programs that are used in 
applications. Using them we can precisely define structural 
properties. Properties of the structural classes can be 
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demonstrated. Schemata give us a tool by which we can rigorously 

formulate and prove statements that every programmer intuitively 
knows. He have used schemata to make a kind of distinction between 
semantic and syntactic extensions to programming languages. The 
intent of the restriction that functions be uninterpreted rs to try to 
prevent our mathematics from falling into what Perlis likes to call 
the "Turing Machine Tar Pit." By using uninterpreted function symbols 
we can prove both analytic and constructive theorems about classes of 
programs. In the analytic theory the mathematical properties of the 
structural classes is expounded. In the constructive theory the 
process by which schemata can be constructed from goal oriented 
language such as PLANNER. The intention is only partially realized 
and we must search for other natural mathematical structures to impose 
on out schemata in order to obtain a more realistic theory of semantic 
extensions to programming languages. He are continuing to investigate 
what gains in efficiency can be obtained from the following extensions 

to programming languages: 

recursion 

backtrace control structure 
PLANNEE primitives 
Locations as a type 
resets 

free identifiers 
parallel evaluation 

replacement operators for constructors. 
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identity test as 


prinsiti ve 
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10. Index of Procedures 


The type hierarchy is given at the beginning of chapter 4. 
The syntax primitives are given after the function BEAD. The page 
number gives the explanation of the procedure. 


Index of Procedures 


397 

188 

150 

150 

187 

149 

149 

149 

149 

177 

134 


f * 

! * 
! + 

! ♦ 
* 

♦ 

/ 




180 


180 

AGS 

149 

ACTIVE 

179 

ACTOR 

79 

ACTOB-CALLER 

99 

ACTOR-FUNCTION 

77 

AGAIN 

111 

ALL 

178 

ALPHABETIC 

154 

ALTER!-PERSISTENT 

191 

ALTERI-TENTATIVE 

192 

AND 

93 

AND? 

92 

ANTECEDENT 

210 

ARC 

133 

ARGS 

171 

AS 

191 

ASCENDING? 

148 

ASSERT!-PERSIST!NT 

215 

ASSEBTI-TENTATIVE 

214 

ASSIGNED? 

171 

AT 

133 
167 


ATC 
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ATOM!-CONSTRUCTOR 
ATOMl-DECC MPCS HR 
BE 

BINDINGS 

BITS 

BLOCK 

BLOCKBIND 
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CALL 

CALL 

CALL 

CALL 

CANDIDATES 

CATCH 

CHANNEL 

CHABACTER 

CHARACTER-VECTOR 

CHOP 1-PERSISTENT 

CHOP!-TENTATIVE 

CLAUSE 

CLAUSE 

CLAUSE-OF 


146 

186 

178 

171 
146 
157 
109 
140 

172 
146 
111 

99 

120 

101 

213 

94 

154 

154 

86 

139 

139 

239 

238 

239 


CLOSE 


154 




CLOSUBE 

COND 

CONSEQUENT 

CONTAINS 

CONTINUE 

COPY 

CURBENT 

CURRENT? 

DAGGER 

DEBUG 

DEC!-PERSISTENT 

DEC!-TENTATIVE 

DECLARATION 

DECLARE 

DECLARED 

DELETE-PRONT 

DELETE-REAR 

DESCENDING? 
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EDIT 

EITHER 

ELEHENT 

EHPTY 

EMPTY? 

END-BLOCK 


130 

94 

208 

183 

128 

134 

223 

219 

181 

170 

147 

147 
179 

99 

167 

153 

153 

148 

154 
198 

81 

183 

183 

130 

157 
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ERASE!-PER SI STENT 

ERASE! -TENTATIVE 
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ERROR 
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EXHAUST 

EXPT 

EXTENSION 
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FAIL 

FAIL 

FAILPCIN.T 

FIELDS 

FINALIZE 
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FOR 

FOR 
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FORK 

FRAH1 

FRONT 

FUNCTION 

GATE 

GENLOC 


219 

218 

211 

170 

106 

235 

149 

86 

189 

112 

235 

96 

187 

231 

233 

185 

113 

231 

240 

127 

171 

152 

72 

227 

151 


GET 

GET!—NO—monitor 

GETC 

GIVEN 

GOAL? 

GOALS 

GREATER 

GREATER* 

HAS 

HEAD 

HOHOGENEOOS 

IDIVIDE 

IN 

INC!-fERSISTENT 

INCI-TENTATIVE 

INCREASING? 

INDEFINITE 

INDEX 

INDICATOR 

* 

INITIAL 

>" x,- .*?;. \ 

INSEBT-FBONT 

*v-‘ r: ‘ -t 

INSERT-REAR 

•' f - K . V 

■i V >v t 

INSTANTIATE 

i* ' 

' ■+. ■ . 

INTEND 

’f 

<r; 

: / . 
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132 


167 


191 

S . 

225 

■- • 

225 

•• 

187 
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187 

c . 

^ ■.> . • f 

181 

• V 

'.f 

134 

' > V J . 

V ~ 

, • -V- ' . 

88 

'i f >: - 

• f 

148 
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151 
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INTEBROPT 

INVOKE 

IS 

IS-ACTOR 
IS? 

ISOHOHPHIC? 

ITOPIE 

IVECTOB 

LAST? 

LENGTH 

LESS 

LBSS= 

LINEAH 
LINK 

LIST!-CONSTSDCTOH 

* M ' 

LISTS-DECOHPdSEfi 

LOCATIVE 

LOCK 

LOCKED? 

LOCKEB 

LORES 

HACBO 

HATCH 

HATCH? 
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129 

118 


105 

136 

143 

143 

133 
140 
186 
186 
183 
157 
142 
185 

134 
168 
169 
169 
154 

78 

106 

105 

178 




MAX 

MEMBER? 

MIN 

MONAD 

MONAD? 

MONITOR 

NAME 

NEXT 

NEXTCfl 

NODE!—CONSTRUCTOR 
NODE l-DECOPOSER 
NON 
NOT? 

NUMBER 

OBLIST 

OF 

OF-TYPE 

ON 

OPTIONS 

OR 

OR? 

OVERALL 

PERSIST 

PERSISTENT 

PNAME 


150 

142 

150 

183 

130 

164 

171 

133 

157 

145 

186 

177 

93 

186 

156 
182 
191 

157 
181 

92 

92 

294 

232 

104 

146 
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POP 

POET 

POWER 

PRECEDES 

PRIMARY 

PRIN 1 

PRINC 

PRINT 

PROCBJE nd 

PROCEDURE 

PROCESS 

PROCNAME 

PRODUCT 

PHODUCT-OF 

PROG 

PROTECT 

PROTECTION 

PUSH 

PUT!“NO-MONITOR 
PUT!-PERSISTENT 
PUT!-TENTATIVE 
PUTC!-PERSISTENT 
PUTC!-TENTATIVE 
PUT LCC S—PE BS15 T E NT 
PUTLCC!—TENTATIVE 


152 

122 

189 

184 

226 

155 

155 

156 
110 
171 
119 
171 

82 

189 

106 

163 

164 
152 
138 

137 

138 
167 
167 
151 
151 











PUTBEST!-PEBSIST ENT 

138 

PUTSEST!-TENTATIVE 

138 

QUOTE 

106 

BEAD 

158 

BEADCH 

157 

BEAB 

153 

BEPEAT 

112 

BEPLACE 

184 

ABSOLVE 

239 

BEST 

131 

BESTOBE 

97 

BETBACT 

166 

BETBY 

230 

BING 

152 

BULE 

98 

SELECT 

182 

SET-ALABM 

90 

SET-TIMEB 

90 

SHABE 

145 

SIGNED-BITS , 

” 146 

SI MI IA B? 

135 / 

STACK 

15 21 

STAB 

181 

STATE 

226 H. 


STEP 
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STOP 

128 

STOHAGE 

166 

STRAIGHTEN 

103 

STRAIGHTEN-UP 

104 

STRING!-CONSTRUCTOR 

145 

STRING l-DECOHPCSEB 

185 

STRUCTURE 

182 

STRUCTURE? 

129 

SUBGOAL 

225 

SUBSTITUTE 

141 

SUM-OF 

188 

SUPPRESS 

106 

SUSPEND 

128 

SWITCH 

228 

SWITCH 

226 

TAIL 

134 

TBHPCBARY 

101 

TEHPORIZE 

102 

TEHPROG 

227 

TERHINATE 

i* 

128 

TOP 

140 

TRAILER 

156 

TYPE 

166 

TYPE-VECTOR 

85 

UNASSIGN 

172 
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^ * 

UNEX1END 86 

UNFALSE 91 

UNIQUE 230 

UNIQUELY? 141 

UNIQUIZE 140 

UNLOCK 170 

UNHONITOB 166 

UHPHCTECT 163 

UNSET—ALABM 90 

UNSET-TIMEB 90 

UNSBABE 144 

UPDATE 226 

UPPEB 154 

VALUE 151 

VABIABIES 239 

VECTOB1-CONSTBUCTOB 145 

VECTOB S-DECOMPCSEB 185 

VBL 177 

BAIT-CALL 126 

WAIT-GET 132 

WHEN 179 


105 






